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

Oleksandr Otenko oleksandr.otenko at oracle.com
Mon Mar 23 08:53:00 EDT 2015

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 


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 <mailto: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
>>     <mailto: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/42311e46/attachment.html>

More information about the Concurrency-interest mailing list