P2
The description of OrderAccess::fence is currently given as:
// Finally, we define a "fence" operation, as a bidirectional barrier.
// It guarantees that any memory access preceding the fence is not
// reordered w.r.t. any memory accesses subsequent to the fence in program
// order. This may be used to prevent sequences of loads from floating up
// above sequences of stores.
but later is this snippet:
// Use
// release_store_fence to update values like the thread state, where we
// don't want the current thread to continue until all our prior memory
// accesses (including the new thread state) are visible to other threads.
The visibility property of the fence() is not clearly documented but is critical for correct operation of algorithms utilising the dekker-duality - such as the safepoint porotocol.
There is an interesting discussion at:
https://blogs.oracle.com/dave/entry/qpi_quiescence
where Dice states in relation to "fences" (on x86 and SPARC):
"That is, they don't force anything to happen -- such as coherence messages on the bus -- that were not already destined to occur. Instead, they simply enforce an order, momentarily reconciling program and memory order."
This might be misconstrued as fences not ensuring visibility, but it simply means that it is done by "passive" means. Given the Dekker sequences:
st B, x
fence
ld A
and
st A, y
fence
ld B
either the ld A sees y, or the ld B sees x, or possibly both. But it is not possible that neither x nor y are seen.
This requirement needs to be clearly documented and the implementations use the appropriate platform barrier instructions.
// Finally, we define a "fence" operation, as a bidirectional barrier.
// It guarantees that any memory access preceding the fence is not
// reordered w.r.t. any memory accesses subsequent to the fence in program
// order. This may be used to prevent sequences of loads from floating up
// above sequences of stores.
but later is this snippet:
// Use
// release_store_fence to update values like the thread state, where we
// don't want the current thread to continue until all our prior memory
// accesses (including the new thread state) are visible to other threads.
The visibility property of the fence() is not clearly documented but is critical for correct operation of algorithms utilising the dekker-duality - such as the safepoint porotocol.
There is an interesting discussion at:
https://blogs.oracle.com/dave/entry/qpi_quiescence
where Dice states in relation to "fences" (on x86 and SPARC):
"That is, they don't force anything to happen -- such as coherence messages on the bus -- that were not already destined to occur. Instead, they simply enforce an order, momentarily reconciling program and memory order."
This might be misconstrued as fences not ensuring visibility, but it simply means that it is done by "passive" means. Given the Dekker sequences:
st B, x
fence
ld A
and
st A, y
fence
ld B
either the ld A sees y, or the ld B sees x, or possibly both. But it is not possible that neither x nor y are seen.
This requirement needs to be clearly documented and the implementations use the appropriate platform barrier instructions.