[concurrency-interest] Relativity of guarantees provided by volatile

Vitaly Davidovich vitalyd at gmail.com
Fri Aug 17 18:44:31 EDT 2012


That's an interesting question.  I think you mean whether JVMs (at least in
the context of this mailing list) will attempt to perform such
optimizations? The CPU doesn't know what a volatile variable is - it's a
language construct, of course.

There's been some similar discussion here in the past.  One example is
whether a write is ever guaranteed to be observed - think cooperatively
scheduled system.  Or perhaps the store buffer is so large that the write
simply lingers there indefinitely; I think most people today assume that
this doesn't happen and that it ultimately gets drained (without explicit
fences, that is).

I will say that it's been stated all over the web that if you write a
volatile value in thread A and then read that value in thread B and those
things happen in that chronological order, that one will see the write from
A immediately (assume no other writers of that memory).  Technically, the
JMM doesn't require that in this case- it only imposes order with respect
to other operations, not timeliness.  However, I don't see how JVM vendors
can break this behavior, even if it conforms to today's JMM spec - there's
just too much potential pain to customers.

Hardware vendors have the same issue - too much change that's negatively
observed by software isn't going to fly.  They're much more likely to add
new optional instructions than to modify existing behavior.

Sent from my phone
On Aug 17, 2012 5:27 PM, "Marko Topolnik" <mtopolnik at inge-mark.hr> 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/4d275121/attachment.html>


More information about the Concurrency-interest mailing list