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 [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss