[Mpi3-rma] RMA proposal 1 update

[Underwood, Keith D]

No, lock and lockall are variants of the same primitive in the same synchronization/exposure/completion model.  And, it is not collective - then it would just be MPI_Win_fence()...

Keith


----- Original Message -----
From: mpi3-rma-bounces at lists.mpi-forum.org <mpi3-rma-bounces at lists.mpi-forum.org>
To: MPI 3.0 Remote Memory Access working group <mpi3-rma at lists.mpi-forum.org>
Sent: Wed May 26 09:51:59 2010
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
mpi3-rma at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma