[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

Oleksandr Otenko 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 
sufficient.

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.


Alex


PS
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...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141210/6d0682e1/attachment-0001.html>


More information about the Concurrency-interest mailing list