This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)


On Apr 15 2011, Janne Blomqvist wrote:


Indeed, I assumed you were discussing how to implement CAF via shared memory. If we use MPI, surely the implementation of MPI_Barrier should itself issue any necessary memory fences (if it uses shared memory), so I don't think __sync_synchronize() would be necessary?

It doesn't have any such semantics. Any fences are issued by MPI_Wait, but see below.

And, as
Richi already mentioned, the function call itself is an implicit
compiler memory barrier for all variables which might be accessed by
the callee. Which implies that any such variables must be flushed to
memory before the call and reloaded if read after the call returns.
So, in this case I don't think there is anything to worry about.

Not in a threaded context, or with shared memory segments!


Mere function calls have no effect whatsoever on memory consistency
between threads, and you really, but REALLY, want to avoid doing full
memory barriers more than you can help.  For complicated reasons, they
can be more expensive than MPI_Barrier, though they are at least sane
and reliable (unlike 'fences').

If the majority of the code is going to be common between an MPI and
a shared memory implementation, explicit synchronisation is needed,
though it might well be a dummy call under MPI.


Regards, Nick Maclaren.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]