6b6b09b4   
   From: pete@versatilecoding.com   
      
   On 2012-05-26 20:46:18 +0000, Rani Sharoni said:   
      
   > On May 25, 2:28 am, Pete Becker  wrote:   
   >> On 2012-05-24 09:11:58 +0000, Rani Sharoni said:   
   >>> Thanks for the explanation. I see your point. std::create-thread is a   
   >>> full memory barrier so for example there is no need for additional   
   >>> barriers in order to access (from the new thread) memory that was   
   >>> initialized before the create-thread call (i.e. no re-ordering is   
   >>> allowed by the caller).   
   >>   
   >> There are two things that are enforced by barriers: no re-ordering, and   
   >> cache coherence. For those who aren't up on this stuff, no re-ordering   
   >> means the compiler can't rearrange the code in ways that invalidate the   
   >> read/write rules. Cache coherence means that the hardware can't   
   >> rearrange reads and writes. The underlying hardware issue is that,   
   >> typically, with multiple cpus you have multiple caches; a write by one   
   >> cpu writes data to its cache; a read by another cpu may read from its   
   >> own cache or from main memory; if the contents of the first cache   
   >> haven't been written to main memory, the read won't see the result of   
   >> that write.   
   >   
   > I used to also think so hence had great fear from the overhead/poor-   
   > scalability of barriers in case that cache flushes are required for   
   > each usage. After some reading I realized that the HW is taking a   
   > great deal to avoid this overhead by assuring that caches are always   
   > coherent (at least data caches, instruction caches coherency is less   
   > interesting since they are mostly read only). cache controllers are   
   > using heady duty machinery like MESI to assure coherency.   
      
   Well, yes, some hardware architectures do more than others to ensure   
   coherence. But when explaining the issues involved in ensuring that   
   data changes are visible across threads, the explanations are often   
   messy, even when they're MESI. (sorry, couldn't resist). Invoking magic   
   doesn't help describe the problem.   
      
   > ...   
   >   
   > Interesting reading about memory barriers on several architectures:   
   > http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf   
   >   
      
   Yup. Paul is one of the folks who helped design the C++ memory model.   
      
   --   
    Pete   
   Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The   
   Standard C++ Library Extensions: a Tutorial and Reference   
   (www.petebecker.com/tr1book)   
      
      
         [ 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)