From: dave@boostpro.com   
      
   on Fri Aug 26 2011, Alexander Terekhov  wrote:   
      
   > Dave Abrahams wrote:   
   > [...]   
   >> Note: don't assume that just because you have only a single CPU or core   
   >> you are safe from these effects: compiler writers generally assume that   
   >> your code deserves no more protection from cross-thread confusion just   
   >> because your threads are running on a single core, and they don't go out   
   >> of their way to make sure you'll observe sensible effects unless you   
   >> correctly use the special CPU instructions to ensure that your threads   
   >> have a consistent view of the world.   
   >   
   > No, compiler reordering aside, no special CPU instructions regarding   
   > memory ordering/barriers are needed if a multithreaded program is   
   > restricted to run on a single core/uniprocessor (not have more than one   
   > thread running at the same time). For a uniprocessor, all fences/barrier   
   > instructions can be just ignored (they are not needed). If you have   
   > contrary evidence, please point to it.   
      
   I don't; I think I misspoke.  What I meant to say was "unless you   
   correctly use synchronization to ensure..."  My point is that in   
   general, even on a uniprocessor you shouldn't consider it safe to modify   
   shared state without synchronization.   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
         [ 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)