0fec0957   
   From: marc.glisse@gmail.com   
      
   Andreas Wallner  wrote:   
      
   > I think it's pretty hard (or impossible) to get an atomic counter   
   > right using the interface you described.   
   > What is hindering a thread from, e.g.:   
   > thread A calls load(), sees writing is safe    
   > thread B calls load(), sees writing is safe   
   > thread B increments your atomic   
   > thread B does some operations, does not release the object  switch>   
   > thread A increments your atomic << shouldn't happen   
   > thread A does some operations   << shouldn't happen   
   >   
   > If I understood your expected usage wrong, please correct me.   
   >   
   > Classically you would have a different API for you atomics, like:   
   > int load();   
   > bool store( int expected, int new); // returns wrong when expected !=   
   > current value of the atomic   
   >   
   > This way you are safe from the scenario above, since the increment of   
   > thread B would fail, and it would not get the write access to the   
   > object.   
   >   
   > Your above example would look like:   
   >   
   > int count = load();   
   > if( count == 0 && store( 0, 1)) cleanup();   
      
   Thank you for answering.   
      
   > From your description, it sounds like you are considering the use of   
   this counter as a lock, whereas I only want to use it for reference   
   counting, something similar to a shared_ptr.   
      
   Ideally, the only 2 functions I would have are ++ (add a reference,   
   when I copy the object) and -- (when I destruct the object, and it   
   returns something telling me if that was the last reference). I add a   
   store function only for initialization, but a default constructor that   
   sets the counter to 0 would be enough. And I could do without a load,   
   I only add it to optimize an "unshare" function (if there is a single   
   reference, don't do anything, but if it is shared, make the object   
   point to a fresh copy of the data that it now owns).   
      
   > For those compiler you can have a look at:   
      
   Yes, I have a list:   
   __sync_add_and_fetch, atomic_inc_uint, OSAtomicIncrement32,   
   _InterlockedIncrement, plus some inline asm implementations. But   
   hopefully std::atomic will soon make all of them useless.   
      
   > The advantage: the compilers already see those intrinsics as memory   
   > barriers, and they should be portable across platforms.   
      
   I am precisely trying to do away with as many memory barriers as I   
   can...   
      
      
   --   
         [ 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)