home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 31,573 of 33,346   
   Francis Glassborow to All   
   Re: atomic counter   
   16 Oct 11 16:09:47   
   
   0b751a3e   
   From: francis.glassborow@btinternet.com   
      
   On 16/10/2011 14:28, SG wrote:   
   > On 15 Okt., 20:34, Alexander Terekhov wrote:   
   >> Pete Becker wrote:   
   >>   
   >> [...]   
   >>   
   >>> That's why most programmers should stick to sequentially consistent   
   >>> program models. They're easier to analyze and easier to get right.   
   >>   
   >> The real world runs on multiprocessors that are NOT sequentially   
   >> consistent and programmers should understand memory models in the most   
   >> relaxed form as a basic programming skill, I think.   
   >   
   > Why should they? It's not like programmers have to implement highly   
   > performant concurrent data structures like queues or hashtables every   
   > day. That's a job for some super smart expert. These low level memory   
   > model aspects are for experts to build nice and easy-to-use libraries   
   > on. As long as programmers have a vague idea of what a data race is,   
   > what they can do to avoid them (amotics, mutexes and locks) and as   
   > long as they can read a library's documentation everything should be   
   > fine. There is no need for average Joe to get dirty with things beyond   
   > sequential consistency. I actually consider myself to be average Joe   
   > w.r.t. this part of the language. But hey, if you want to write an   
   > article about it (like "c++ memory model for dummies") I'm all ears...   
   >   
      
   However programmers should not be writing multi-threaded code unless   
   they understand the significance of multi-processors/cores. Too many do   
   not yet grasp the basic fact that multi-threaded code that works ok on a   
   single processor core can fail unpredictably when the hardware is   
   upgraded and the program runs using more than one core.   
      
   BTW is there a way to mark a program so that the OS will not assign   
   multiple cores to it even if it is multi-threaded?   
      
   Francis   
      
      
   --   
         [ 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca