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