[mpich-discuss] MPI_WIN_LOCK and MPI_MODE_NOCHECK assert

[Dave Goodell]

Nightly tarballs are available here: http://www.mpich.org/static/tarballs/nightly/master/

In particular, this tarball should contain the change that Jim mentioned: http://www.mpich.org/static/tarballs/nightly/master/mpich-master-v3.0.2-54-g882c80f.tar.gz

-Dave

On Feb 22, 2013, at 4:39 PM CST, Jim Dinan wrote:

> Hi Jaric,
> 
> I pushed out the MODE_NOCHECK changes as a part of 9e68dcf86.  Feel free to try them out.
> 
> Best,
> ~Jim.
> 
> On 2/21/13 9:20 AM, Jim Dinan wrote:
>> 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
>>> 
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss