[concurrency-interest] Problem #2: Reordering volatile and nonvolatile stores
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
> 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
> 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
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