On 01/23/2013 04:22 PM, Dave Goodell wrote: > If you don't want to write inline assembly, this might be your best bet. > But on TSO systems like x86, you only need a "compiler barrier". > In x86 inline assembly syntax, this looks like: > > __asm__ __volatile__ ( "" ::: "memory" ) > > This prevents GCC (and compilers that correctly support this syntax) > from reordering accesses across this statement or making assumptions > about the state of memory across this point.
Yeah, you're right. Thanks for bringing clarity to my (concurrently-) fried brain. To make a stab at an executive summary, then: * in intentionally racey code, we need to worry about both hardware and compiler reordering stores. That requires, at a minimum, inserting suitable load and store fences. * on x86/x86_64, we only need to worry about the compiler reordering stores, since the hardware promises not to. That means all we need is a compiler barrier, as you show -- probably on both sides of both the load and store. * regardless of the above 2 points, since C++11 allows compilers to assume code is race free, we can't rule out the possibility that the compiler does some other legal transformation which makes the code not work as the authors intended. Because of this last point, overall I'm still with Pat LoPresti, who summarised the situation admirably thus: "There is no such thing as a benign data race. Ever." (v-users, 4 Dec 2012) IMO, the idea that some races are harmless is a dangerous myth that we should try to stamp out. J ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
