[concurrency-interest] Relativity of guarantees provided by volatile

Marko Topolnik mtopolnik at inge-mark.hr
Wed Aug 22 17:51:45 EDT 2012

On 22. kol. 2012., at 19:18, Zhong Yu wrote:

> On Wed, Aug 22, 2012 at 1:39 AM, Marko Topolnik <mtopolnik at inge-mark.hr> wrote:
>> 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
> Can you give the reference to this provision? (I didn't see an
> explicit one; though it's quite natural, since the set of actions
> should be countable)
> precludes bunching together an infinite amount of busy-wait flag
> checks, all reading the stale false value.

This would be it:


However, it is much clearer if you refer to Manson, Pugh, "The Java Memory Model", Section 7, and especially Figure 9.



More information about the Concurrency-interest mailing list