[concurrency-interest] Relativity of guarantees provided by volatile

Yuval Shavit yshavit at akiban.com
Fri Aug 17 19:30:25 EDT 2012


Sure, but it could decide that the execution order is [w1, w2, w3, r]. In
fact, as far as we know, the thread may have been scheduled such that that
was the clock-time ordering, too.

On Fri, Aug 17, 2012 at 7:21 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> Two volatile writes emit a store-store barrier in between, which to me
> means they cannot be collapsed and must be made visible in that order (on
> non-TSO this would require a h/w fence).  In other words, I don't think
> compiler can remove the redundant stores as if this was a non-volatile
> field, where it's a perfectly valid (and good) optimization.
>
> Sent from my phone
> On Aug 17, 2012 7:18 PM, "David Holmes" <davidcholmes at aapt.net.au> wrote:
>
>> **
>> How does it violate the JMM? There is nothing to establish that any read
>> has to have occurred prior to w=3. An external observer may say "hey if
>> we'd actually written w=1 at this point then the read would see 1" but that
>> is irrelevant. The program can not tell the other writes did not occur.
>>
>> David
>>
>> -----Original Message-----
>> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
>> *Sent:* Saturday, 18 August 2012 9:12 AM
>> *To:* dholmes at ieee.org
>> *Cc:* Marko Topolnik; concurrency-interest at cs.oswego.edu
>> *Subject:* Re: [concurrency-interest] Relativity of guarantees provided
>> by volatile
>>
>> I don't think the writes to w can be reduced to just the last one as it
>> would violate the JMM.  R may only see the last one due to interleaving
>> though. Not sure if that's what you meant.
>>
>> Sent from my phone
>> On Aug 17, 2012 7:03 PM, "David Holmes" <davidcholmes at aapt.net.au> wrote:
>>
>>> Hi Marko,
>>>
>>> I think the "surprise" is only in the way you formulated this. Said
>>> another
>>> way a write takes a finite amount of time from when the instruction
>>> starts
>>> to execute to when the store is actually available for a read to see.
>>> (Similarly a read takes a finite amount of time.) So depending on those
>>> two
>>> times a read and write that happen "around the same time" may appear to
>>> have
>>> occurred in either order. But when you program with threads you never
>>> know
>>> the relative interleavings (or should never assume) so it makes no
>>> difference how the program perceives the order compared to how some
>>> external
>>> observer might perceive it.
>>>
>>> As for your optimization to "chunk" volatile writes, I don't see a
>>> problem
>>> here if you are basically asking if given:
>>>
>>> w = 1;  // w is volatile
>>> w = 2;
>>> w = 3;
>>>
>>> that this could be reduced to the last write alone? I see no reason why
>>> not.
>>> Without some additional coordination between a reader thread and the
>>> writer
>>> thread, reading w==3 is a legitimate outcome. If you are thinking about
>>> how
>>> the hardware might chunk things then that is a different matter. We have
>>> to
>>> use the hardware in a way that complies with the memory model - if the
>>> hardware can't comply then you can't run Java on it.
>>>
>>> David Holmes
>>> ------------
>>>
>>> > -----Original Message-----
>>> > From: concurrency-interest-bounces at cs.oswego.edu
>>> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Marko
>>> > Topolnik
>>> > Sent: Saturday, 18 August 2012 7:24 AM
>>> > To: concurrency-interest at cs.oswego.edu
>>> > Subject: [concurrency-interest] Relativity of guarantees provided by
>>> > volatile
>>> >
>>> >
>>> > Consider the following synchronization order of a program
>>> > execution involving a total of two threads, R and W:
>>> >
>>> > - thread R begins;
>>> >
>>> > - thread R reads a volatile int sharedVar several times. Each
>>> > time it reads the value 0;
>>> >
>>> > - thread R completes;
>>> >
>>> > - thread W begins;
>>> >
>>> > - thread W writes the sharedVar several times. Each time it
>>> > writes the value 1;
>>> >
>>> > - thread W completes.
>>> >
>>> > Now consider the wall-clock timing of the events:
>>> >
>>> > - thread R reads 0 at t = {1, 4, 7, 10};
>>> > - thread W writes 1 at t = {0, 3, 6, 9}.
>>> >
>>> > As far as the Java Memory Model is concerned, there is no
>>> > contradiction between the synchronization order and the
>>> > wall-clock times, as the JMM is wall-clock agnostic. However, I
>>> > have yet to meet a single Java professional who wouldn't at least
>>> > be very surprised to hear that the specification allows this.
>>> >
>>> > I understand that the SMP architecture that dominates the world
>>> > of computing today practically never takes these liberties and
>>> > makes the volatile writes visible almost instantaneously. This
>>> > may change at any time, however, especially with the advent of
>>> > massively parrallel architectures that seem to be the future. For
>>> > example, an optimization technique may choose to chunk many
>>> > volatile writes together and make them visible in a single bulk
>>> > operation. This can be safely done as long as there are no
>>> > intervening read-y actions (targets of the synchronizes-with
>>> > edges as defined by JLS/JSE7 17.4.4).
>>> >
>>> > Now, my questions are:
>>> >
>>> > 1. Is there a loophole in my reasoning?
>>> >
>>> > 2. If there is no loophole, is there anything to worry about,
>>> > given that practically 100% developers out there consider as
>>> > guaranteed something that isn't?
>>> >
>>> >
>>> > -Marko
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Concurrency-interest mailing list
>>> > Concurrency-interest at cs.oswego.edu
>>> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>> >
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120817/c4556036/attachment-0001.html>


More information about the Concurrency-interest mailing list