On Tuesday, September 13, 2016 at 9:48:06 AM UTC+8, Caleb Spare wrote: > > See > https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong. > > >
I've read this article before and the second reading hasn't done much to improve my impression. The premise in the first example, that multiple threads updating the same memory location in a non-atomic fashion constitutes "innocent" code, is about as strawman as they come. Forget the data race, there's an obvious race condition here! And unless C++ atomic operations are wildly different from those I have experience with (java mainly), the suggested "correct" code fixes only the data race and not the race condition. The remaining examples sound indistinguishable from compiler bugs. You have multiple threads concurrently accessing a 'stop' variable, and yet the compiler believes that "the stop variable can't be accessed concurrently by other threads"? Might want to consider some escape analysis before making that assumption... You define a function-local variable intended to hold a copy of some shared memory, and the compiler decides to read the shared memory twice? Thanks buddy! The last one takes the cake - you read from a memory location and the compiler TURNS IT INTO A WRITE??? And problems emerging from all of these get blamed on the programmer's "racy code" instead of a broken compiler? W. T. F. > Most Go programmers consider programs with data races to be logically > incorrect / broken. > Maybe there are good reasons to consider them such, but this article has not convinced me of any. -sqweek -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
