[concurrency-interest] Double Checked Locking in OpenJDK
dl at cs.oswego.edu
Tue Aug 14 16:07:41 EDT 2012
On 08/14/12 15:25, Zhong Yu wrote:
> If we strengthen JMM just a little bit, by extending the memory
> semantics of final fields to all fields, then there won't be this kind
> of confusions - as long as an object is unmodified after construction,
> it is thread-safe immutable, and all of its publications are safe
> The only objection (from David Holmes) was that the final field
> semantics could be expensive on some platforms. But final fields have
> always been promoted without mentioning any downsides, therefore that
> argument probably doesn't have many sympathizers.
Some of us are reading these posts with a huge sense of deja vu.
These issues were debated back in the early days of JSR133.
The decision about which way to go on this is still controversial.
Here's a summary off the top of my head:
The two main points for prohibiting reorderings of field assignments
with assignments using reference of the constructed objects remain:
1. It's the obvious thing that anyone who thinks about
concurrency and objects would first expect. Not doing it
leads to errors because people can't keep senseless-looking rules
in their heads all the time.
2. Instruction-level implementation is free on TSO (x86/sparc) and
the added compiler reordering constraints don't seem to detectably
hurt code (and might even improve it sometimes).
And the main two points for allowing them except in the
case of final fields (i.e., the current rules):
1. Most (but not all) of the cases where the rule would come into
play that do not entail final fields are racy/buggy anyway, so
relying on it will often lead to other errors.
2. Instruction-level implementation on some machines is very
expensive. The DEC Alpha was the killer example long ago. POWER
and ARM remain expensive. The upcoming ARMV8/ARM64 much less so.
More information about the Concurrency-interest