GCC Explorer is great and I use it on a semi-regular basis. I often use it to show what kinds of optimizations a modern compiler will do. Just yesterday I was using it to show someone how a piece of code like:
int launched = 0;
// ...
start_thread(...);
while (!launched) {}
could result in an endless loop since the compiler just rewrote it to 'if(!launched) { while(true){} }'. The person had the thread write to 'launched' and expected the first thread to exit the loop once launched had been set to 1.
Great tool. I hope it doesn't get a HN hug of death.
C has atomic types now also. And I believe in general that volatile only prevents elision of reads and stores, but not optimization in general. That works for many cases (and I think it would work here) but it doesn't solve data races in general.
Unless 'launched' was directly or indirectly local to the stack frame, I don't see how this optimisation is legal. In general your compiler has to assume values will change across an opaque function call.
To expand on what to3m said. The code was transformed into something like this:
int launched = 0;
start_thread(...);
if (!launched) {
while (true) {}
}
That's a perfectly legal optimization. The integer here isn't atomic and if another thread modifies the variable, that would be a data race and those have undefined behavior. Therefore, the compiler can assume that there is no race and move the comparison out of the loop.
Changing it to be "std::atomic<int> launched;" fixes that problem.
>That's a perfectly legal optimization. The integer here isn't atomic and if another thread modifies the variable, that would be a data race and those have undefined behavior. Therefore, the compiler can assume that there is no race and move the comparison out of the loop.
In this case, the data race is fairly minimal, since we're talking about a 4 byte integer being used as a boolean flag. Operations like x = 1 for 4 byte ints are pretty much guaranteed to be atomic with x86, and worst case, you go through 1 more iteration of your loop than you would have otherwise(which your code should account for at any rate with locking for critical sections). Any change to the int should cause the while loop to exit.
It should be a volatile(C pre C11) or atomic(C++11/C11) integer if you're passing it between threads, though.
It presumably checks launched just before the while loop, after the start_thread call is complete, under the assumption that whatever start_thread might have done to that variable has been done. (An implementation could have some kind of markup on the thread creation function so that the compiler can infer the pointed-at memory has become volatile... but I doubt anybody actually does that. Much easier to let the code fuck up and blame the programmer ;))
Great tool. I hope it doesn't get a HN hug of death.