Previously there was no documentation at all, which seems entirely inappropriate
given how subtle memory ordering is.
- rGHC Glasgow Haskell Compiler
No Unit Test Coverage
- Build Status
Buildable 22066 Build 50942: [GHC] Linux/amd64: Continuous Integration Build 50941: [GHC] OSX/amd64: Continuous Integration Build 50940: [GHC] Windows/amd64: Continuous Integration Build 50939: arc lint + arc unit
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.
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! :)
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.