shared locks

Skip to first unread message

Rama Vasudevan

Dec 23, 2020, 4:58:30 PM12/23/20
to mpi4py

We have a code implementation that utilizes windows and shared locks to enable different processes to read data. We do this by e.g.

windows_iterations[agent_id].Lock(agent_id,lock_type=MPI.LOCK_SHARED, assertion=0)
windows_iterations[agent_id].Get([localiter, 1, MPI.INT], agent_id)

Perhaps I am understanding this wrong, but the shared lock seems to introduce synchronization to the code, when the purpose is to create a method to read data whilst other processes have not completed yet (i.e., make it fully asynchronous). Is this expected behavior, or is there an issue on the backend?

Kind Regards,

Lisandro Dalcin

Dec 24, 2020, 5:00:40 AM12/24/20
I'm not an export on the RMA programming model. That being said, I guess you know the Lock()/Unlock() calls are not about locking in the thread sense. 
Lock()/Unlock() are really begin/end access epochs. Thus, handling these access epochs necessarily require synchronization, and MPI implementers may do it at the Lock()/Unlock() call or at the Unlock() call.
But again, I'm not an expert. I suggest you look for a more authoritative source.

Lisandro Dalcin
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)

Rama Vasudevan

Dec 29, 2020, 2:12:16 PM12/29/20
to mpi4py
Thanks Lisandro. I found out it was because running such code on the MPI implementation (Spectrum) we are using requires a special flag. So, this is not an issue with mpi4py. It works now. 
Reply all
Reply to author
0 new messages