6bb95e55   
   From: anthony.ajw@gmail.com   
      
   On Aug 18, 10:32 am, darkknight...@gmail.com wrote:   
   > If I use a mutex of some kind like this   
   >         acquire-mutex   
   >         execute code/ modify shared variables   
   >         release-mutex   
   >   
   > For this to work, the compiler is not allowed to move code across the   
   > acquire/release statements.  Does the documentation for a mutex   
   > usually say this?   
      
   The mutex docs usually says something akin to "writes made by a thread   
   prior to a call to unlock are visible to any subsequent thread that   
   acquires the lock", which pretty much implies the lack of code   
   movement.   
      
   > Anyway, assuming the above is true, is not a simple solution to the   
   > singleton problem something like this   
   >         if (ptr == 0)  // line1  - inexpensive   
   >         {   
   >             acquire-mutex1   
   >             if (ptr == 0)   
   >             {   
   >                ptr1 = &singleton;  // whatever   
   >                acquire_mutex2;   
   >                ptr = ptr1;   
   >                release_mutex2;   
   >             }   
   >             release-mutex1   
   >         }   
   >   
   > At line1, if ptr is non-zero, we know for sure that the singleton   
   > object has been fully constructed.  No volatile anywhere.  The mutexes   
   > would also provide the needed memory barriers.   
   >   
   > Would this work?   
      
   This isn't an improvement over the DCLP. The main problem is that   
   unsynchronized reads can occur out of order, so a thread can read ptr   
   in the if() outside the lock, and see a non-zero value, but then read   
   the singleton members and see stale uninitialized values. Without the   
   necessary synchronization, the writes to the singleton's members might   
   be stuck in the cache of the writing processor, whilst the reading   
   processor has a stale copy in it's cache.   
      
   If you want to avoid the mutex lock, you need to use atomic ops for   
   the read of ptr. See my blog post on this:   
      
   http://www.justsoftwaresolutions.co.uk/threading/multithreading-in-c++0x-par   
   t-6-double-checked-locking.html   
      
   Anthony   
   --   
   Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/   
   just::thread C++0x thread library             http://www.stdthread.co.uk   
   Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk   
   15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No.   
   5478976   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)