+Dima вс, 10 мая 2015, 8:50, Dean McNamee <de...@chromium.org>:
> 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.
