[Mpi3-rma] RMA proposal 1 update

Wed May 26 11:04:42 CDT 2010

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

On 05/26/2010 11:00 AM, Underwood, Keith D wrote:
> 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