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