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

Oleksandr Otenko oleksandr.otenko at oracle.com
Fri Mar 20 14:52:03 EDT 2015


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.

>     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.


Alex

>
> ---
> Marko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150320/759e960b/attachment.html>


More information about the Concurrency-interest mailing list