Double Checked Locking & Java 5

Hi,

does anybody know if the "proposed memory model" that is mentioned in
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html is
actually part of Java 5, i.e. if DCL is supposed to work with volatile fields or
if this is still something that cannot work reliably even in Java 5 VMs?

I found this comment in JSR-133 that makes be believe that it's still broken:

"There exist a number of common but dubious coding idioms, such as the
double-checked locking idiom, that are proposed to allow threads to communicate
without synchronization. Almost all such idioms are invalid under the existing
semantics, and are expected to remain invalid under the proposed semantics."

So what's the deal?

Thanks,
Sascha

3 comments

The latest updates where from starting of 2004. So I think it's nearly dead.
Isn't there a dedicated mailing list?

Sascha Weinreuter schrieb:

Hi,

does anybody know if the "proposed memory model" that is mentioned in
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html is
actually part of Java 5, i.e. if DCL is supposed to work with volatile fields or
if this is still something that cannot work reliably even in Java 5 VMs?

I found this comment in JSR-133 that makes be believe that it's still broken:

"There exist a number of common but dubious coding idioms, such as the
double-checked locking idiom, that are proposed to allow threads to communicate
without synchronization. Almost all such idioms are invalid under the existing
semantics, and are expected to remain invalid under the proposed semantics."

So what's the deal?

Thanks,
Sascha

0

If I read the specification
(http://java.sun.com/docs/books/jls/third_edition/html/memory.html)
correctly, Double Checked Locking should work correctly using a volatile
field on a properly implemented 5.0 JVM. However, I wonder if you then
wouldn't also loose any performance advantages the DCL idiom has in the
first place, because a memory barrier would be needed on any read of the
field. See also The JSR-133 Cookbook for Compiler Writers
(http://gee.cs.oswego.edu/dl/jmm/cookbook.html).

Still, I would very much advice against using it.

Bas

Sascha Weinreuter wrote:

Hi,

does anybody know if the "proposed memory model" that is mentioned in
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html is
actually part of Java 5, i.e. if DCL is supposed to work with volatile fields or
if this is still something that cannot work reliably even in Java 5 VMs?

I found this comment in JSR-133 that makes be believe that it's still broken:

"There exist a number of common but dubious coding idioms, such as the
double-checked locking idiom, that are proposed to allow threads to communicate
without synchronization. Almost all such idioms are invalid under the existing
semantics, and are expected to remain invalid under the proposed semantics."

So what's the deal?

Thanks,
Sascha

0

Thanks Bas, it was more a question out of curiosity than a plan to actually
making use of it. I'm also not sure about the possible performance gain,
especially because AFAIK synchronization in current HotSpot JVMs isn't that
expensive any more.

But thanks a lot for having a look at it ;)

Sascha

0

Please sign in to leave a comment.