On Fri, 8 Apr 2005, David Schwartz wrote:
Right, and the standard doesn’t require them to. Nor does it require them to perform the operations in order as seen by another processor.
OK- my apologies. I was misreading what you were saying. We're on the same page.
Right, and I’m arguing not that the compilers aren’t conforming but that the standard is being misread. What I’m specifically arguing against is the view that the standard says what the compiler must do and then the hardware is free to do something different.
Yep. And part of the problem is that the C standard is incredibly vague when it comes to defining the precise execution environment. That, and most hardware engineers I've met have not been up on the specific intricticies of the C memory model. Add to that the eternal push for more performance, and you have a situation ripe for subtle nonconformancies.
What makes the situation worse is that some race conditions can have incredibly narrow windows, so that hitting them is literally one in a billion chance. Consider the code:
extern volatile int foo;
foo += 1;
I know a number of programmers who would assume that's atomic. The fact that it compiles to a single instruction on the x86 helps promote this view. But it's not. Intel's doc clear spells out that unless you add the lock prefix, it's not atomic. However, for the race condition to happen, the other modification of foo has to occur at *precisely* the right clock cycle- one cycle either way and there it won't be hit. That's a one in a billion shot.
Of course, all this means is that the race condition will be hit in production, at the client's site in outer mongolia, and not somewhere convient, like in the debugger while you're testing.
If in doubt, my advice is to lock. And if it requires even a casual reading the standard spec, you're in doubt.
Brian
