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

Peter Veentjer alarmnummer at gmail.com
Tue Aug 22 17:29:28 EDT 2006


Hmmm.. that sounds reasonable. Thank you.

On 8/22/06, Jeremy Manson <jmanson at cs.umd.edu> wrote:
> 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.
>
>
>                                         Jeremy
>


More information about the Concurrency-interest mailing list