[concurrency-interest] Relativity of guarantees provided byvolatile

David Holmes davidcholmes at aapt.net.au
Fri Aug 17 19:34:21 EDT 2012


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

EXACTLY! Once the write has happened the read is subsequent. But that isn't
the same as saying "once the write has started". The thing is, does "coming
after" mean "starting after" or "completing after"? I would argue completing
after. In fact I seem to recall that the full formal model for the JMM
assumed that instructions executed instantaneously, so that this kind of
discussion would not arise. If this discussion were on the JMM list where it
belongs someone may have already pointed that out. :) I may be
mis-remembering of course.

David

  -----Original Message-----
  From: Nathan Reynolds [mailto:nathan.reynolds at oracle.com]
  Sent: Saturday, 18 August 2012 9:25 AM
  To: dholmes at ieee.org
  Cc: David Holmes; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Relativity of guarantees provided
byvolatile


  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 | Consulting Member of Technical Staff | 602.333.9091
  Oracle PSR Engineering | 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) 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 | Consulting Member of Technical Staff | 602.333.9091
      Oracle PSR Engineering | 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/20120818/54577568/attachment.html>


More information about the Concurrency-interest mailing list