[concurrency-interest] Enforcing total sync order on modern hardware

Marko Topolnik marko at hazelcast.com
Mon Mar 23 11:56:50 EDT 2015

So your analogy to IRIW is established by introducing a whole new reading
thread. Such an analogy fails to capture the essence of my scenario: I am
interested precisely in the case where the "reading-writing" thread
observes its own writes in addition to the "timer" thread's writes. The
goal is to analyze the tension between the desire to win performance
through store forwarding and the need to stay sequentially consistent. It
was my impression that the distributed nature of QPI messaging would result
in the processors grabbing more of the liberties allowed by Intel's
specification, which specifically excludes my scenario from the ordering
guarantee. As Aleksey pointed out, this is not the case because an MFENCE
instruction provides a stronger guarantee than that: the coherence layer
will have resolved the value at the stored location before the load
instruction asks for its value.


On Mon, Mar 23, 2015 at 1:53 PM, Oleksandr Otenko <
oleksandr.otenko at oracle.com> wrote:

>  Out of all outcomes IRIW permits, choose those that have the fourth
> thread observe 1 then 0 - ie there exists a thread which observed Wv1 occur
> before T9. Now you are looking at your case with three threads. Your case
> does not add more outcomes, only chooses a subset of those in IRIW.
> Alex
> On 20/03/2015 22:05, Marko Topolnik wrote:
>  On Fri, Mar 20, 2015 at 7:52 PM, Oleksandr Otenko <
> oleksandr.otenko at oracle.com> wrote:
>>  On 20/03/2015 18:12, Marko Topolnik wrote:
>>  On Fri, Mar 20, 2015 at 5:45 PM, Oleksandr Otenko <
>> oleksandr.otenko at oracle.com> wrote:
>>>  No, that doesn't answer the question. You need to modify how
>>> happens-before is built - because happens-before in JMM and in some other
>>> model are two different happens-befores. If you get rid of synchronization
>>> order, then you need to explain which reads the write will or will not
>>> synchronize-with.
>>  I think it's quite simple: the read may synchronize-with any write as
>> long as that doesn't break happens-before consistency.
>>  It seems quite naive, too. The problem is that currently the read
>> synchronizes-with *all* writes preceding it, but observes the value set
>> by the *last* write. Here you need to define somehow which write the
>> read observes - you need to somehow define which of the writes is "last"
>> and what the other readers are allowed to think about it.
>> It doesn't seem to be explained in one sentence.
>  It is a quite lightweight exercise to rigorously specify this in terms
> of Lamport's clocks; but I concede that, lacking a shared intuition, it
> will take more than a sentence to communicate. I hesitate to turn this into
> a treatise on the application of Lamport's clocks to the JMM, so I'm
> letting it rest.
>>    I am only involved in this discussion because you said it isn't IRIW,
>>> but I see all signs that it is. I remember the discussion here doubting
>>> that IRIW should be supported, and I appreciate the arguments, but without
>>> the specification it is difficult to continue a meaningful discussion.
>>  That's strange to hear since I have pointed out exactly why it's not
>> IRIW: if we broaden the definition such that it covers my case, then we
>> must accept that Intel allows IRIW to happen because it explicitly excludes
>> the writing thread from the guarantee which is supposed to disallow it.
>>  Rwt6 and Rrt6 are reduntant. If you remove them, it becomes IRIW. Rwt6
>> only witnesses the particular ordering of some operations in IRIW - it
>> forbids some of the outcomes from IRIW, but doesn't add new ones. Rrt6 is
>> meaningless.
>  IRIW involves four independent threads and six events. My example
> involves only three threads, so there must be something wrong in calling it
> "exactly IRIW". Apparently you have in mind some quite flexible definition
> of IRIW, but I cannot second-guess what it might be.
>  ---
> Marko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150323/2dcd9e5a/attachment.html>

More information about the Concurrency-interest mailing list