[concurrency-interest] Enforcing total sync order on modern hardware
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest