[mpiwg-rma] Fence + threads

[Jeff Hammond]

What's the use case? I don't honestly see a good one. Passive target with
flush(_all) makes more sense with threads.

On Friday, June 20, 2014, Balaji, Pavan <balaji at anl.gov> wrote:

>
> The standard itself doesn’t seem to disallow it.  This means that, at
> least, MPICH is incorrect here.  I’d expect most MPICH derivatives to be
> incorrect for this as well.
>
> However, I’m trying to understand if that was the intention (and just
> forgotten to describe in the standard).  We never discussed this in the
> MPI-3 working group.
>
>   — Pavan
>
> On Jun 20, 2014, at 12:46 PM, Dave Goodell (dgoodell) <dgoodell at cisco.com
> <javascript:;>> wrote:
>
> > On Jun 20, 2014, at 11:16 AM, "Balaji, Pavan" <balaji at anl.gov
> <javascript:;>> wrote:
> >
> >>
> >> Is the following code correct?  Two threads of a process both do the
> following:
> >>
> >> MPI_PUT
> >> MPI_PUT
> >> MPI_WIN_FENCE
> >>
> >> Collectives are not allowed on the same communicator simultaneously.
>  But we don’t say anything similar for windows.
> >
> > As I read it, it should be fine according to the standard as long as you
> haven't specified any assertions that would cause you to be lying to the
> implementation.
> >
> > When we don't specifically disallow concurrent multithreaded operations,
> then the general threading text seems to allow this.  See MPI-3, p.483,
> l.1-11:
> >
> > ----8<----
> > The two main requirements for a thread-compliant implementation are
> listed below.
> >
> > 1. All MPI calls are thread-safe, i.e., two concurrently running threads
> may make MPI calls and the outcome will be as if the calls executed in some
> order, even if their execution is interleaved.
> >
> > 2. Blocking MPI calls will block the calling thread only, allowing
> another thread to execute, if available. The calling thread will be blocked
> until the event on which it is waiting occurs. Once the blocked
> communication is enabled and can proceed, then the call will complete and
> the thread will be marked runnable, within a finite time. A blocked thread
> will not prevent progress of other runnable threads on the same process,
> and will not prevent them from executing MPI calls.
> > ----8<----
> >
> > So, absent some external inter-thread synchronization, it will be
> undefined exactly which epoch the MPI_PUTs end up in.
> >
> > -Dave
> >
> > _______________________________________________
> > mpiwg-rma mailing list
> > mpiwg-rma at lists.mpi-forum.org <javascript:;>
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org <javascript:;>
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>


-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20140620/10fa137c/attachment-0001.html>