[concurrency-interest] Problem #2: Reordering volatile and nonvolatile stores
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
> 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
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;
a = 1;
done = true;
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