[concurrency-interest] Relativity of guarantees provided by volatile

Marko Topolnik mtopolnik at inge-mark.hr
Wed Aug 22 02:39:14 EDT 2012


On 22. kol. 2012., at 01:40, Boehm, Hans wrote:
>> 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.

If thread 2 never gets scheduled then the value of the flag is not stale (that's what I said---"read a stale value"). This JMM provision precludes bunching together an infinite amount of busy-wait flag checks, all reading the stale false value.

-Marko




More information about the Concurrency-interest mailing list