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

Peter Veentjer alarmnummer at gmail.com
Tue Aug 22 16:45:31 EDT 2006


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?


More information about the Concurrency-interest mailing list