[concurrency-interest] Relativity of guarantees provided by volatile

Vitaly Davidovich vitalyd at gmail.com
Fri Aug 17 19:11:59 EDT 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120817/8d288f05/attachment-0001.html>


More information about the Concurrency-interest mailing list