One difference between a lockall and multiple nested locks is that lockall takes a single lock type for the entire set. With multiple nested locks, the user could make a thousand calls to Win_lock, with arbitrary shared and exclusive locks, and the implementation would have to keep track of the thousand lock states. Rajeev

-----Original Message----- From: Rajeev Thakur [mailto:[email protected]] Sent: Wednesday, May 26, 2010 12:36 PM To: 'MPI 3.0 Remote Memory Access working group' Subject: RE: [Mpi3-rma] RMA proposal 1 update

Implementation wise, allowing nested locks (with exclusive) may not be a trivial change.

Rajeev

...

-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Wednesday, May 26, 2010 11:52 AM To: MPI 3.0 Remote Memory Access working group Subject: Re: [Mpi3-rma] RMA proposal 1 update

On 05/26/2010 11:40 AM, Rajeev Thakur wrote:

...

...

Yes, you do -- so my notes (a) and (b) below are only for the "if lockall is only for shared locks" case.

Not just lockall. The user would have to assert that no other process will call regular lock with an exclusive lock.

Correct. But if it's a different synchronization primitive, we don't have to care about that case.

...

...

I think there are two parts here -- (1) to remove the restriction on whether only one lock can be acquired; and (2) to provide the lockall convenience function.

(1) is a minor change to the standard and should be included.

If you allow nested locks with exclusive locks, the user code may deadlock depending on what the implementatation chooses to do: block on a lock or defer everything until unlock. The user code may work in some cases, and may not work in other cases.

That's a user error, and is to be dealt by other tools outside of the scope of MPI.

There are a lot of ways a user can screw up even within the current MPI standard. We can't drop flexibility because someone might screw up.

-- Pavan

-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma