From: Brian B. <bri...@gm...> - 2012-12-05 18:17:33
|
It would be better to use atomics (with proper memory order), which can solve this kind of problem without unintended consequences. As mentioned before, this still may not be as maintenance friendly as locking, but at least it will be correct. Brian On Wed, Dec 5, 2012 at 9:29 AM, Julian Seward <js...@ac...> wrote: > > On Tuesday, December 04, 2012, Patrick J. LoPresti wrote: > > There is no such thing as a benign data race. Ever. > > <soapbox> > > Well said. I couldn't have put any of this better myself. > > Having spent a considerable amount of time working on Helgrind and then > using it to chase races in some big hairy C++ codes, I became very > skeptical of the "oh it's only a harmless race" arguments. However, > I gave up shouting about it after a while since it just made me look > like a tiresome pedant hellbent on criticising people's clever go-faster- > by-avoiding-locking schemes. > > IMO, the idea that some races are harmless is a dangerous myth that > we should try to stamp out. > > I also noticed that threaded code that relies on unsynchronised > accesses is hard for newcomers to understand and reason about, so it > tends to be a maintenance hazard. > > In some ways, the fact that the Intel architecture guarantees to > deliver stores in-order (x86-TSO), and is therefore somewhat tolerant > of such racery, is a disadvantage. I think people would take this > stuff more seriously if racey code got trashed more often by machines > with memory systems that do reordering, such as Power7. > > </soapbox> > > J > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |