Talk:Double-checked locking

message: From here: 
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)
thread_title:  Java version doesn't really reduce overhead on modern JVMs 

message: 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)
thread_title:  VC++ information seems to be wrong for x86 at least 

message: (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 (talk • contribs) 09:54, 5 August 2009 (UTC)
thread_title:  How about a derivation of the original DCL that avoids using fences in C++? 

message: For instance, have a look at  
where use of atomic operations is suggested and illustrated.
Ptyxs (talk) 15:11, 4 July 2012 (UTC)
thread_title:  Why not a paragraph about C++11 ? 

message: 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)
thread_title:  Why not a paragraph about c++98/03? 

message: Hello fellow Wikipedians,
I have just modified  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:
*Added archive https://web.archive.org/web/20060620041255/http://purevirtuals.com:80/blog/2006/06/16/son-of-a-bug/ to http://purevirtuals.com/blog/2006/06/16/son-of-a-bug/
*Added archive https://web.archive.org/web/20060620041255/http://purevirtuals.com:80/blog/2006/06/16/son-of-a-bug/ to http://purevirtuals.com/blog/2006/06/16/son-of-a-bug/
*Added archive https://web.archive.org/web/20060412081055/http://www.oaklib.org:80/docs/oak/singleton.html to http://www.oaklib.org/docs/oak/singleton.html
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 02:48, 16 December 2016 (UTC)
thread_title:  External links modified 

message: Anybody can verify the change of data in this edit special:diff/954987354...? The history of the IP contributions makes me somewhat suspicious. --CiaPan (talk) 10:54, 5 May 2020 (UTC)
replies: text: Wrong page number, but I found it. The page number could be different editions or something. Mathnerd314159 (talk) 21:34, 5 August 2023 (UTC)
thread_title:  Please verify a reference 

message: The C++ version constructs a lock_guard, then loads with memory_order_relaxed, which makes sense because the mutex-lock provides a memory fence. But then at the end it does s_instance.store(p, std::memory_order_release);. Can't that also be relaxed since it is followed by the RAII mutex unlock? —Ben FrantzDale (talk) 14:21, 9 November 2020 (UTC)
replies: text: I thought I understood why, but then I re-read it. If it were a std::atomic<bool> and if we were doing additional work inside the lock, then I think I see why it needs to be s_instance.store(p, std::memory_order_release): While the mutex-unlock is a fence, inside the lock, we need be sure that the store isn't reordered before the other work. However, in this case, the only work is p = new Singleton() and the atomic store, so I don't think (?) the store could be reordered before p = new Singleton() even if it were s_instance.store(p, std::memory_order_relaxed). In the general case, where it's doing other work inside the lock, then I do think  s_instance.store(p, std::memory_order_release) is needed. —Ben FrantzDale (talk) 14:14, 11 November 2020 (UTC)
thread_title:  Memory order for store?