0c600df8   
   From: mcmccarty@gmail.com   
      
   On Aug 18, 4:32 am, darkknight...@gmail.com wrote:   
   > I have a follow-up question to my question on the double checked   
   > locking problem   
   >   
   > 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?   
   >   
   > 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?   
      
   I believe you still have the problem of visibility.  There is no   
   guarantee when the effects of 'ptr = ptr1;' will be visible to other   
   threads.  That is the problem that std::atomic<> solves.   
      
      
   Mike   
      
      
   --   
         [ 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)