[Mpi3-rma] Next RMA Telecon

Pavan Balaji balaji at mcs.anl.gov
Mon Dec 26 21:00:59 CST 2011


On 12/26/2011 08:48 PM, Torsten Hoefler wrote:
> Why does:
>
> win_fence()
> if(rank == 0) { initialize_window(); MPI_Barrier(); }
> else MPI_Barrier();
> win_fence()
> // all procs read written data here
>
> not work for Ron's use-case? Are you talking about another use-case?

I see.  I thought you were referring to using point-to-point/collectives 
alone without any RMA calls.

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

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.

Btw, I assume the following would be valid?

Win_allocate_shared(shared_mem, &shared_win);
Win_create(shared_mem, &remote_win);  /* overlapping window */

P0:
Win_lock_all(SHARED, &shared_win);
Recv(P1);
Barrier();

ALL_OTHER_PROCESSES_SHARING_SHARED_WIN:
Barrier();

REMOTE_PROCESS:
Win_lock(EXCLUSIVE, P0, remote_win);
Put(P0, remote_win);
Win_unlock(P0);
Send(P0);

The idea is that a process gets a lock on a shared memory region and 
uses it for remote RMA communication.

  -- Pavan

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



More information about the mpiwg-rma mailing list