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

Joe Bowbeer joe.bowbeer at gmail.com
Tue Aug 22 17:23:46 EDT 2006

On 8/22/06, Peter Veentjer <alarmnummer at gmail.com> 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.
> The consequence is that a volatile field now has two responsibilities:
> 1) make sure that a value is read-from/written-to main memory instead of cache
> 2) prevent reordening with non volatile fields en synchronize them
> with main memory before a volatile field is called.
> I don't understand why the old behaviour is bad. The mistake of using
> a non volatile field was made while information needs to be exchanged
> in multiple threads. This sounds acceptable to me, so why is the
> second responsibility added? Is this done to make jmm easier to use?
> Or are their other reasons I'm missing?

First of all, the old behavior was never completely specified, or
implemented, so it's hard to compare new with old.

As I understand the current spec, volatile reads and writes are
synchronization actions, similar in some ways to tiny one-statement
synchronized blocks.

To be effective as synchronization actions, it's important that the
rest of the code not move around too much.  Would you think it OK if
code outside of a synchronized block were allowed to jump over the
block?  (That would render ReentrantLock useless.)

Also see http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile

More information about the Concurrency-interest mailing list