[concurrency-interest] Problem #2: Reordering volatile and nonvolatile stores

Jeremy Manson jmanson at cs.umd.edu
Tue Aug 22 17:00:46 EDT 2006

Peter Veentjer wrote:
> I have a question about the "Problem #2: Reordering volatile and
> nonvolatile stores" mentioned in the article by Brian Goetz
> http://www-128.ibm.com/developerworks/library/j-jtp02244.html
> In the old vm it was allowed to reorden volatile and non volatile
> stores and this could lead to non volatile fields that are not set.
> But why is this bad? It is the consequence of being a non volatile
> field.

It is bad because the old behavior was basically useless, on account of 
the fact that it didn't support any of the use cases people actually 
have for volatiles.  Certainly, the overwhelming majority of the use 
cases I've heard of require this behavior.

To pick one use case at random, if you have:

int a = 0;
volatile boolean done = false;

Thread 1:
a = 1;
done = true;

Thread 2:
while (!done)
r1 = a;

Pretty much everyone wants the assignment to a to be seen by the second 
thread if the loop finishes.

Now, I suspect you will say that a should also be volatile.  But imagine 
what happens if a is a pointer to some enormous data structure, only 
some of which you can actually edit.  Should all of the reachable fields 
be made volatile, as well?  Ultimately, every field would need to be 
tagged volatile, just in case anyone ever wanted to use it in any sort 
of multithreaded context.


More information about the Concurrency-interest mailing list