Talk:Double-checked locking
From Wikipedia, the free encyclopedia
Please also see: http://java.sun.com/developer/technicalArticles/Programming/singletons/ This web site also confirms that the only way to solve the singleton pattern problem when using multiple threads in Java is by making the constructor synchronized. —Preceding unsigned comment added by Thosylve (talk • contribs) 19:16, 3 March 2008 (UTC)
the proposed solution for DCL in Java with the volatile keyword doesn't work
see here: http://www.javaworld.com/jw-02-2001/jw-0209-double.html?page=1 and here: http://www-128.ibm.com/developerworks/java/library/j-dcl.html and here: http://jcp.org/en/jsr/detail?id=133
Even the referenced source itself states that it does not work yet: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html —Preceding unsigned comment added by Tcorbat (talk • contribs) 09:37, 3 September 2007 (UTC)
uh, AFAIK double checked locking is broken on JAVA, but it can work nicely in C and C++. the problem is, that in Java, you can't insert the required memory barriers...
Good news, Mr./Mrs. 84.157.213.97, perhaps you could add the details to the article? Seriously, I think the article should make clear how it applies to different languages, and should include a formal demonstration of how it can fail in a given memory model (or a proof that it cannot fail :)). PJTraill 18:32, 5 March 2006 (UTC) Aha, I realise that since I last looked a number of things have changed... But a summary of which versions x platforms it can work on would be useful. PJTraill 18:46, 5 March 2006 (UTC)
-
- According to this article it is also problematic in C++. I found this link on the article page. Perhaps it was added after your comment or you just didn't bother to look at it. http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
Contents |
[edit] Java example which uses “initialized” boolean seems to be broken
The Java example which uses the boolean variable to check whether the instance has already been initialized seems flawed and non-functional. “instance” and the call of the constructor in no way depends on the value of “initialized”, so the compiler or the virtual machine executing the code might reorder (swap) the two instructions in the synchronized block. (Or does the Java™ Language Specification explicitly prohibit that???) 87.236.198.84 12:33, 17 May 2007 (UTC)
-
- Indeed, since the JVM can reorder the instructions the example is equivalent to the earlier (helper == null). iirc this is also mentioned in the "The "Double-Checked Locking is Broken" Declaration" article. So this should be removed. Initworks 09:49, 23 May 2007 (UTC)
-
-
-
- Sorry for dummy question but why not:
-
-
class Foo {
private Helper helper = null;
private boolean helperInitialized = false;
public Helper getHelper() {
if (helperInitialized == false) {
synchronized(this) {
if (helperInitialized == false) {
// Variant One:
helper = new Helper();
helperInitialized = helper.toString() != null;// or helper.calcFlag()
// Variant Two:
try {
helper = new Helper();
} finally {
helperInitialized = true;
}
}
}
}
return helper;
}
}
-
-
-
- --Shurup 06:20, 14 Jule 2007 (UTC)
-
-
[edit] DCL isn't a "design pattern"
How is double-checked locking a "design pattern"? It's really just a programming idiom that may happen to be used in the implementation of some patterns. It's easy to see the difference -- applying a pattern takes work, but using this idiom just takes plugging in the variable names of your choice. Anyone disagree?
[edit] Java version doesn't really reduce overhead on modern JVMs
From here: [1]
The whole point of double-checked locking was that it was supposed to be a performance optimization, designed to eliminate synchronization on the common code path, largely because synchronization was relatively expensive in very early JDKs. Not only has uncontended synchronization gotten a lot cheaper since then, but the new changes to the semantics of volatile make it relatively more expensive than the old semantics on some platforms. (Effectively, each read or write to a volatile field is like "half" a synchronization -- a read of a volatile has the same memory semantics as a monitor acquire, and a write of a volatile has the same semantics as a monitor release.) So if the goal of double-checked locking is supposed to offer improved performance over a more straightforward synchronized approach, this "fixed" version doesn't help very much either.
-- nyenyec ☎ 17:50, 4 December 2007 (UTC)
