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.
