[mpich-discuss] MPI_WIN_LOCK and MPI_MODE_NOCHECK assert

[Jim Dinan]

Hi Jaric,

In current and previous releases of MPICH, MPI_MODE_NOCHECK was only 
used to optimize active target communication.  As part of the MPI-3 
work, we've also added a MPI_MODE_NOCHECK optimization to passive target 
communication.  This feature should hopefully make it out to our git 
repo this week and be included in the in the next release.

MPI_MODE_NOCHECK essentially asserts that the epoch can begin 
immediately at the target.  If you are using exclusive locks, this means 
that the lock is uncontended.  If you are using shared locks, this means 
that the lock is uncontended, or that all other processes are also using 
shared lock.

In terms of the implementation for passive target, MODE_NOCHECK allows 
us to piggyback the lock request on the first RMA operation, since the 
user has asserted that the lock request will succeed immediately.

Best,
  ~Jim.

On 2/20/13 9:11 PM, Jaroslaw Zola wrote:
> I have a question regarding implementation of the MPI_MODE_NOCHECK assertion
> for MPI_WIN_LOCK. Is current mpich implementation taking advantage of this
> hint? Also, according to the standard:
>
> MPI_MODE_NOCHECK - no other process holds, or will attempt to acquire,
> a conflicting lock, while the caller holds the window lock. This is useful when
> mutual exclusion is achieved by other means, but the coherence operations that
> may be attached to the lock and unlock calls are still required.
>
> Are two concurrent locks from two different MPI processes followed by MPI_GET
> (i.e. given window is not modified but read only) considered conflicting?
>
> Thanks!
>
> - Jaric
>
>
>
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
>