Just to put this specific issue to a close, maybe some of the analysis people could share their thoughts. Would hate to hang up this patch on a broader question about undefined behaviour in general, and try to only declare something wrong here if there is an articulable concern about this specific data access.
On Fri, May 8, 2015 at 9:18 PM, Matthew Dempsky <mdemp...@chromium.org> wrote: > On Fri, May 8, 2015 at 12:47 AM, Dean McNamee <de...@chromium.org> wrote: >> >> Umm, I wouldn't say they're technically broken, > > > Unfortunately, then you'd be wrong. The C++ standard is very clear that > (aside from certain cases like std::atomic) assigning to the same variable > (even via a volatile lvalue expression) from multiple threads is undefined > behavior. > > Using volatile lvalues happens to be mostly okay today, but mostly to > support code bases that predate 2011. That doesn't change what the standard > says though or limit what compilers *could* do in the future. > >> Actually, the example illustrated in 2.4 is quite a different >> situation and does not reflect the code here. > > > I was only refuting your assertion that time::Now's race was safe **because > the writes are redundant**. Section 2.4 of Boehm's paper demonstrates > that's not a sound argument **in general**. > > I.e., if you want to continue arguing that time::Now's race is safe (even > though the C++ standard says otherwise), you'll need a new supporting > argument. > >> in the clock code only *one* value will ever be >> >> written, always the same value. In 2.4 that is not the case. > > > In section 2.4, that is the case. The only source-level modifications to > count that happen in his example are the two "count = 0" assignments in the > left-hand column of page 4. He's using an example of calling f(positives), > which means the "count++" source-level statements will never execute, yet > the unconditional "count = 0" assignments allow the compiler to optimize > assuming otherwise (i.e., the *effective* transformation to using "reg = > count", "reg++", and "count = reg" at the top-left of page 4). > >> I would read it carefully again, > > > Yes, please do, as you seem to have both missed the point of that specific > section as well as the entire conclusion of Boehm's paper: > > "Although there is a perfectly reasonable notion of benign data race at the > level of x86 or similar machine code, the same is not true at the C or C++ > source program level. Standards are increasingly clear about prohibiting > data races." > > >> I am pretty sure compiler writers understand compilers and >> architectures enough to make what they feel is a good decision here. > > > And they've made the decision that source program level data races in C++ > programs are undefined behavior with no guaranteed semantics. -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
