[concurrency-interest] Relativity of guarantees provided byvolatile

Nathan Reynolds nathan.reynolds at oracle.com
Fri Aug 17 19:25:17 EDT 2012


Hmm...  I am getting tripped up on JMM vs Intel memory model vs HotSpot 
implementation.

Dictionary.com says subsequent = occurring or coming later or after; 
following in order or succession.  Given that each read happens 1 unit 
of time after every write, I would think that the read is "subsequent" 
to the write.  In other words, once the write happens, then any read 
operation which starts execution after that point in time will be 
subsequent to the write and hence will see the effects of the write.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 8/17/2012 4:03 PM, David Holmes wrote:
> Nathan,
> Is there a synchronization order here that indicates that the read 
> occurs after the write? "subsequent" is not defined by wall-clock time 
> as externally observed.
> And to batch responses :) Hotspot's implementation requires that all 
> writes will become visible without need for explicit barriers/fences 
> to force that.
> David
>
>     -----Original Message-----
>     *From:* concurrency-interest-bounces at cs.oswego.edu
>     [mailto:concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of
>     *Nathan Reynolds
>     *Sent:* Saturday, 18 August 2012 8:47 AM
>     *To:* concurrency-interest at cs.oswego.edu
>     *Subject:* Re: [concurrency-interest] Relativity of guarantees
>     provided byvolatile
>
>     > I have yet to meet a single Java professional who wouldn't at
>     least be very surprised to hear that the specification allows this.
>
>     Add me to the list of surprised.
>
>     Here's an excerpt from the specification.
>
>     A write to a volatile variable (§8.3.1.4)
>     <http://docs.oracle.com/javase/specs/jls/se5.0/html/classes.html#36930>
>     /v/ synchronizes-with all subsequent reads of /v/ by any thread
>     (where subsequent is defined according to the synchronization order).
>
>     http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#17.4.4
>
>     Doesn't this mean that R will always read 1 since the read occurs
>     after the write?
>
>     Nathan Reynolds
>     <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
>     Consulting Member of Technical Staff | 602.333.9091
>     Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
>     On 8/17/2012 2:24 PM, Marko Topolnik wrote:
>>     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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120817/64369244/attachment-0001.html>


More information about the Concurrency-interest mailing list