[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
oleksandr.otenko at oracle.com
Wed Dec 10 12:04:17 EST 2014
I don't see David's email, so I'll respond here.
On 09/12/2014 18:15, Martin Buchholz wrote:
> On Mon, Dec 8, 2014 at 8:35 PM, David Holmes <david.holmes at oracle.com> wrote:
>> ..TSO with global visibility is not
>> sufficient to achieve IRIW. So what is it that x86 and sparc have in
>> addition to TSO that provides for IRIW?
It is precisely TSO that enables IRIW on x86.
TSO means all threads agree on the order in which the stores appear.
Write buffers relax this to mean "all other threads agree on the order
in which the stores appear". To make it strong again, it is sufficient
to preclude loads in the same thread that stores values, to go ahead
before the stores become visible to the others. mfence then is just such
a mechanism - it is a fence that does not allow the loads to go ahead
before the preceding stores became visible to other threads. So all
threads agree on the order of volatile stores.
TSO then is the synchronization order of stores from JMM. It seems
possible to show that the total order of loads is not needed on TSO -
program order of loads and synchronization order of loads with stores is
ARM/Power then are different. They don't have a way to provide TSO -
they don't provide synchronization order from JMM. Instead, they can
only provide program order of stores. The tiny difference in the
semantics of DMB and MFENCE is that DMB only gives /local/ guarantees -
the loads and stores in the same thread do not commit until the
preceding stores were flushed; but MFENCE additionally provides a
/global/ guarantee that /all threads agree on the order/ of the stores.
sketch of the argument that TSO is enough would go like this.
Programs can detect JMM is not adhered to, if they can observe a
condition for which there is no total order of volatile operations
*/consistent with program order and synchronizes-with/*. (That's how
valid executions are defined anyway). But each thread already guarantees
issuing both loads and stores consistent with program order and
synchronizes-with. The stores already form a total order, so we only
need to add loads to the total order. Since there are no rules in JMM
precluding the ordering of loads from different threads, just place all
loads that synchronize-with this store or any preceding stores from
Thread 0 preserving program order, then add loads from Thread 1, etc (in
contrast, stores do have rules - eg a store to x can't appear between
another store to x and the load that synchronizes-with it).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest