Document (however vaguely) the semantics of MO_WriteBarrier
Needs ReviewPublic

Authored by bgamari on Jul 31 2018, 4:05 PM.

Details

Reviewers
simonmar
trommler
Summary

Previously there was no documentation at all, which seems entirely inappropriate
given how subtle memory ordering is.

bgamari created this revision.Jul 31 2018, 4:05 PM
trommler added a comment.EditedAug 1 2018, 8:21 AM

Linux documentation of memory barriers defines a write barrier as follows:

A write memory barrier gives a guarantee that all the STORE operations
specified before the barrier will appear to happen before all the STORE
operations specified after the barrier with respect to the other
components of the system.
 
A write barrier is a partial ordering on stores only; it is not required
to have any effect on loads.
 
A CPU can be viewed as committing a sequence of store operations to the
memory system as time progresses.  All stores _before_ a write barrier
will occur _before_ all the stores after the write barrier.

Memory reads are explicitly excluded from the ordering. This allows to use more efficient barrier instructions (lwsync instead of sync on PowerPC).
So far we have been using lwsync for MO_WriteBarrier in the PowerPC backend. With the above definition we would have to switch to a sync barrier,
which has higher overhead.

The above document then warns about the need for read barriers:

Note that write barriers should normally be paired with read or data
dependency barriers; see the "SMP barrier pairing" subsection.

Switching to sync as said above, however, would still require read barriers on PowerPC as another processor might still have reordered reads before the
barrier was communicated to that processor.

bgamari added a comment.EditedAug 1 2018, 4:43 PM

Linux documentation of memory barriers defines a write barrier as follows:

[snip]
Memory reads are explicitly excluded from the ordering. This allows to use more efficient barrier instructions (lwsync instead of sync on PowerPC).
So far we have been using lwsync for MO_WriteBarrier in the PowerPC backend. With the above definition we would have to switch to a sync barrier,
which has higher overhead.

Right, this diff was really intended to be a basis for discussion. Frankly, I'm not very certain of the intended semantics of MO_WriteBarrier. I suspect the only person who knows is @simonmar but he is on holiday for at least another week.

Right, this diff was really intended to be a basis for discussion.

My comment was meant as a contribution of an idea to the discussion. Sorry, I should have made that explicit.

michalt added inline comments.
compiler/cmm/CmmMachOp.hs
566

Sorry for nitpicking, but for a non-native speaker having both the negation in the form of "neither ... nor" and "may not" is somewhat confusing. Consider rephrasing this a bit. Thanks! :)

bgamari added inline comments.Aug 21 2018, 10:55 AM
compiler/cmm/CmmMachOp.hs
566

Wow, re-reading this even I'm confused by what I wrote. Thanks!

Perhaps we can avoid negation and say what the guarantee of the barrier actually is.

For example something like this:

Memory operations before the barrier are guaranteed to happen (visible? to all other processors and mechanisms) before memory operations after the barrier.

We would still have to agree if this applies to all memory operations, or for write operations, or something else.