[Mpi3-rma] Next RMA Telecon

[Pavan Balaji]

On 12/26/2011 10:31 PM, Torsten Hoefler wrote:
>> Also, the case I had in mind was using lock/unlock.  If it is valid for
>> the user to do a for loop of Win_lock(exclusive), I'm not sure how we
>> are taking away the MPI implementation burden by not allowing
>> Win_lock_all(exclusive).
> A for loop is a silly user program, having a slow P^2 lock_all
> exclusive (in the extreme case) is a problem in the MPI lib.

True.  Hence the need for a lock_all(EXCLUSIVE).  But if that's not 
provided, there should at least be a fall back option, and the for loop 
is that.

Besides, silly or not, it's a valid MPI program and the MPI 
implementation has to deal with it.

>> More importantly -- even if we want to not allow exclusive locks in
>> WIN_LOCK_ALL, I would suggest retaining the lock_type parameter and say
>> that the behavior of EXCLUSIVE locks is undefined, so that it's future
>> proof in case we want to add it later.  Also, implementations that want
>> to provide it can do so without random hacks or new API functions.
> Yes, I thought about this, however, our original #270 didn't have this
> feature and I decided to revert to the original. We can do a straw vote
> here and fix it quickly. I have no strong opinion.

I'd prefer a straw vote on this.  I don't see any additional burden on 
implementors who don't want to allow it.  But it's much cleaner for 
implementations that decide to allow it.

>> The idea is that a process gets a lock on a shared memory region and
>> uses it for remote RMA communication.
> Yes, that should work but the semantics of overlapping windows are
> hairy.

I think they are quite well defined, and fairly intuitive once you think 
through it.  But that's just personal opinion.

  -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji