2 ms·
It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example: x
by wat10000 8mo ago
It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example:
x = *a;
if (x) y = *b;
The compiler cannot reorder the load of b before the load of a, because it may not be a valid pointer if x is false. But the CPU is free to speculate long ahead, and if the pointer in b isn't valid, that's fine, the CPU can attempt a speculative load and fail.
It's not particularly common and code that has this issue will probably crash only rarely, but it's not too hard to do.
- IshKebab 8mo agoI don't understand your example. That code is correct on both architectures.
- wat10000 8mo agoMemory ordering issues require two sides to manifest, since even the most extreme out-of-order architecture presents itself as in-order to a single thread. Imagine that code was paired with code in another thread that did: *b = newValue; barrier(); *a = 1; We put a barrier here to ensure the stores don't get reordered, since we must write out the new value in b before writing out the flag in a that tells the other code to use it. Paired with this, my example above will work fine on an architecture with strong ordering, but will potentially get a bad value into y on archs with weak ordering. The reader may fetch the value in b first, getting the value before the reassignment. It may then fetch the value in a and see 1. This will cause it to use the old value loaded from *b, which is semantically incorrect in this case even though it's perfectly correct according to the architecture and the language spec. Correct code here would need an acquire barrier on the load of a, paired with a release barrier on the store.