Talk:Double-checked locking

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science  
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

With JVM1.5, using the keyword final and the idiom of eager initialization, you shouldn't need to do double-checked locking to create singleton any more. It is as simple as just declared a field final, and JVM will guarantee the the field is visible only after fully initialized. Pls see link below. AltosAce (talk) 17:55, 7 August 2010 (UTC)

  * http://www.javamex.com/tutorials/synchronization_final.shtml
  * http://renaud.waldura.com/doc/java/final-keyword.shtml


Double Checked Locking works with a ReadWriteLock in Java. The read lock is obtained, the value is checked, and if a write is necessary, the read lock is released and the write lock is obtained. The check must be performed again before writing because another thread may have obtained the write lock in the meantime. Finally the write lock is downgraded to a read lock, and the read lock (either way) is released. http://weblogs.java.net/blog/2006/09/11/rechecking-double-checking 65.82.131.225 (talk) 21:06, 19 April 2010 (UTC)

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 (talkcontribs) 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 (talkcontribs) 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

Java example which uses “initialized” boolean seems to be broken[edit]

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)
The code above looks like it solves the problem w/o volatile. --71.192.157.35 (talk) 13:26, 23 April 2009 (UTC)
A problem is that assignments are not guaranteed to be visible in the same order across different threads. Another thread may never see the updated value of helper, and always return null, or it can see the assignment to helper and helperInitialized before Helper is fully constructed. 217.155.35.160 (talk) 06:42, 3 January 2013 (UTC)
I believe the following code should also work (with the Helper class having a getThis() method that just returns a reference to this:
class Foo { 
   private Helper helper = null;
   public Helper getHelper() {
       if (helper == null) {
           synchronized(this) {
               if (helper == null) {
                   helper = (new Helper()).getThis();
               }
           }
       }
       return helper;
}
--Kod-meister (talk) 16:35, 7 May 2009 (UTC)

DCL isn't a "design pattern"[edit]

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?

Java version doesn't really reduce overhead on modern JVMs[edit]

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)

This is not exactly true. Volatile read/writes are cheaper than any locking since locking itself includes at least a CAS (that includes volatile read/write) and owning thread assignment. Using class initialization to avoid double check idiom had its downsides: classes take extra spaces into the perm gen space. Double check pattern is not a design pattern at any rate. The entire article should be moved away and rewritten. 83.99.131.77 (talk) 22:48, 13 December 2008 (UTC)

VC++ information seems to be wrong for x86 at least[edit]

volatile keyword does not seem to emit memory barrier instructions on x86 so how can it prevent CPU reordering?

http://bartoszmilewski.wordpress.com/2008/11/05/who-ordered-memory-fences-on-an-x86/ —Preceding unsigned comment added by 86.175.44.87 (talk) 18:03, 8 January 2010 (UTC)

It looks to me that the Visual C++ version number specified in the article is incorrect. See http://msdn.microsoft.com/en-us/library/12a04hfd%28v=VS.71%29.aspx - this is for Visual Studio .NET 2003 and mentions nothing about ordering. http://msdn.microsoft.com/en-us/library/12a04hfd%28v=VS.80%29.aspx is for Visual Studio 2005 and specifically mentions ordering. Hence the reference to Visual C++ 5.0 should read Visual Studio 2005 I think. SoftwareDave (talk) 14:31, 3 February 2011 (UTC)

It appears that VC treats volatile as memory barrier as well, at the compiler level, meaning it prevents compiler from reordering memory accesses. I don't think it can prevent CPU reordering without inserting processor-specific memory fences.

C# version should be mentioned as it has been working robustly since 2.0 as well.[edit]

http://msdn2.microsoft.com/en-us/magazine/cc163715.aspx

How about a derivation of the original DCL that avoids using fences in C++?[edit]

(Syntax not checked! Using pthread in this example, but can be any other threading library!)

 class Foo
 { 
 private:
   Helper *helper;
   pthread_key_t localHelper;
   pthread_mutex_t mutex;
 public:
   Foo()
     : helper(NULL)
   {
     pthread_key_create(&localHelper, NULL);
     pthread_mutex_init(&mutex);
   }
   ~Foo()
   {
     pthread_key_delete(&localHelper);
     pthread_mutex_destroy(&mutex);
   }
   Helper *getHelper()
   {
     Helper *res = pthread_getspecific(localHelper);
     if (res == NULL)
     {
       pthread_mutex_lock(&mutex);
       if (helper == NULL)
       {
         helper = new Helper();
       }
       res = helper;
       pthread_mutex_unlock(&mutex);
       pthread_setspecific(localHelper, res);
     }
     return res;
   }
 };

This works because it stores the pointer to the common Helper in a thread-local variable. It has to acquire the lock only the first time the method is called per thread. —Preceding unsigned comment added by Ruestevens (talkcontribs) 09:54, 5 August 2009 (UTC)

Why not a paragraph about C++11 ?[edit]

For instance, have a look at [2] where use of atomic operations is suggested and illustrated. Ptyxs (talk) 15:11, 4 July 2012 (UTC)

Why not a paragraph about c++98/03?[edit]

There is still a huge amount of legacy C++98 code still running, being maintained and being written from scratch for that matter. It would be good to have a section describing the situation pre-C++11, i.e. a summary of Meyers and Alexandrescu's article. 160.83.36.129 (talk) 09:17, 27 July 2016 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 3 external links on Double-checked locking. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—InternetArchiveBot (Report bug) 02:48, 16 December 2016 (UTC)