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

Marko Topolnik marko at hazelcast.com
Fri Mar 20 18:05:50 EDT 2015


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/20150320/6bc98b98/attachment-0001.html>


More information about the Concurrency-interest mailing list