7920393a   
   From: terekhov@web.de   
      
   Mathias Gaunard wrote:   
   >   
   > On Oct 24, 6:46 pm, Alexander Terekhov  wrote:   
   >   
   > > I always thought that C++11 mutex locks can be expressed in terms of   
   > > relaxed C++11 atomic<> operations and acquire/release fences (not the   
   > > same as memory_order_seq_cst fence).   
   >   
   > AFAIK, locking a mutex is a full barrier, not just an acquire barrier.   
   > This is not the case for spinlocks though.   
      
   Who told you that? Spinlocks and mutexes are the same barrier-wise.   
      
   >   
   > Sure, you can do a a full barrier by doing an acquire followed by a   
   > release, but it's possibly more efficient to just do the full barrier.   
   >   
   > > class swap_based_mutex_for_windows { // noncopyable   
   > >   
   > >   atomic m_lock_status; // 0: free, 1/-1: locked/contention   
   > >   auto_reset_event m_retry_event; // slow binary semaphore (windows)   
   >   
   > How is that pseudo-code written only using built-in atomic operations   
   > when there is a reference to a heavyweight kernel-level   
   > synchronization mechanism?   
      
   The code also works with usleep() or somesuch blocking mechanism instead   
   of auto_reset_event.   
      
   regards,   
   alexander.   
      
      
   --   
         [ 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)