[Mpi3-rma] RMA proposal 1 update

[Underwood, Keith D]

I thought you had to assert that there were no exclusive locks anywhere for the shared lock to be a no-op...  Now, we may want that requirement, but I think we have to state it if we do.  I.e. What if somebody uses lock to get an exclusive lock?


----- 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 08:46:59 2010
Subject: Re: [Mpi3-rma] RMA proposal 1 update


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.

With respect to (2) -- I'm OK with keeping this only for shared locks, 
but note that:

(a) if we allow this only for shared locks, it's going to be a no-op for 
all architectures (cache coherent and non-cache coherent).

(b) It's still useful to have in order to be consistent with the user's 
expectation -- that is, once a lockall(SHARED) is done, the user cannot 
do a LOCK(EXCLUSIVE) for example. If we remove this call, the user's 
expectations will break.

Another way to look at this is, to make a "LOCKALL" a fourth form of 
synchronization (a new one), rather than an extension to the LOCK/UNLOCK 
synchronization.

  -- Pavan

On 05/26/2010 10:36 AM, Rajeev Thakur wrote:
> Perhaps we should allow only shared locks with lockall.
> 
> Rajeev 
> 
>> -----Original Message-----
>> From: mpi3-rma-bounces at lists.mpi-forum.org 
>> [mailto:mpi3-rma-bounces at lists.mpi-forum.org] On Behalf Of 
>> Underwood, Keith D
>> Sent: Wednesday, May 26, 2010 8:59 AM
>> To: MPI 3.0 Remote Memory Access working group
>> Cc: rbbrigh at Sandia.gov; bwbarre at Sandia.gov
>> Subject: Re: [Mpi3-rma] RMA proposal 1 update
>>
>> Interesting. We shouldn't lose sight of the fact that 
>> lockall/unlockall when you get an exclusive lock or even when 
>> you don't assert that nobody else has an exclusive lock will 
>> be... complicated.  The advantage of lockall/unlockall is 
>> that there are usage models where it is ok to not take an 
>> exclusive lock and to assert that nobody will.  
>>
>> Keith
>>
>>> -----Original Message-----
>>> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma- 
>>> bounces at lists.mpi-forum.org] On Behalf Of William Gropp
>>> Sent: Wednesday, May 26, 2010 7:07 AM
>>> To: MPI 3.0 Remote Memory Access working group
>>> Cc: rbbrigh at Sandia.gov; bwbarre at Sandia.gov
>>> Subject: Re: [Mpi3-rma] RMA proposal 1 update
>>>
>>> I don't think we talked about it at all - the single lock 
>> restriction 
>>> was simply the consequence of needing a way to define the scope of 
>>> passive target operations and support non-cache-coherent systems 
>>> (don't forget that "lock" isn't a "lock" - its a "begin 
>> access epoch").
>>> Bill
>>>
>>> On May 25, 2010, at 11:28 PM, Torsten Hoefler wrote:
>>>
>>>> On Tue, May 25, 2010 at 10:04:41PM -0600, Underwood, 
>> Keith D wrote:
>>>>> Lockall/unlockall was definitely on the list at the last meeting.
>>>>> There wasn't consensus on many things, but there was on that one 
>>>>> ;-)
>>>> Ok, I added it. See wiki.
>>>>
>>>> We should still discuss this further. It seems like we're adding 
>>>> much functionality and I'm not 100% sure if this is all 
>> compatible 
>>>> with
>>> the
>>>> MPI-2.0 design. Does anybody know the rationale for the one-lock 
>>>> restriction in MPI-2?
>>>>
>>>> All the Best,
>>>>  Torsten
>>>>
>>>> --
>>>> bash$ :(){ :|:&};: --------------------- 
>> http://www.unixer.de/ -----
>>>> Torsten Hoefler         | Research Associate
>>>> Blue Waters Directorate | University of Illinois
>>>> 1205 W Clark Street     | Urbana, IL, 61801
>>>> NCSA Building           | +01 (217) 244-7736
>>>> _______________________________________________
>>>> mpi3-rma mailing list
>>>> mpi3-rma at lists.mpi-forum.org
>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>> William Gropp
>>> Deputy Director for Research
>>> Institute for Advanced Computing Applications and Technologies Paul 
>>> and Cynthia Saylor Professor of Computer Science University of 
>>> Illinois Urbana-Champaign
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mpi3-rma mailing list
>>> mpi3-rma at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>
> 
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

-- 
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