[concurrency-interest] Relativity of guarantees provided by volatile

Boehm, Hans hans.boehm at hp.com
Tue Aug 21 19:40:38 EDT 2012


> From: Marko Topolnik [mailto:mtopolnik at inge-mark.hr]
> 
> > Similar to your concern that consecutive volatile writes can be
> > compressed into the last write, it also seems true that consecutive
> > volatile reads can be compressed into the first read - exactly the
> > kind of optimization to be disabled by C's volatile. It's
> > inconceivable that any JVM will do such optimization on volatile
> > reads, it'll break lots of programs, e.g. busy waits.
> 
> Actually there is already a provision in the JMM (in the original
> paper, at least) that prevents a busy-waiting loop whose condition
> involves a volatile read to forever read a stale value. There can be
> only a finite number of such read actions. But, this is a small
> consolation, really. Most code DOES make a difference between "eternity
> minus one" and "right now".
> 
My recollection is that this is only sort of/mostly of true.  If your entire program consists of

Thread 1:
while (!flag) {}

Thread 2:
flag = true;

There is intentionally no requirement that thread 2 ever be scheduled.  If it's not, that looks a lot like flag having been read once.  If, on the other hand, thread 2 sets flag and then prints "Hello", and you see the "Hello", then I believe you are correct that thread 1 must terminate.

My own feeling is that (under the right safety conditions), it's OK to collapse a bounded, "short" sequence of volatile reads into one, but not an unbounded number.  Java "volatile" is not "C volatile".  C "volatile" is neither intended for, nor safe for, synchronization.  Java "volatile" is not intended for device register access, or for use with setjmp, or ...

Hans



More information about the Concurrency-interest mailing list