Consider this scenario: In a multi-threaded application, there is a shared variable that is modified by only one thread (let's call it Thread A) but read by several other threads (Thread B, C, D).
Here's the sequence of events:
- Thread A updates the value of the shared variable to 1.
- Threads B, C, and D read the value as 1.
- Thread A then changes the value to 2.
- Now, imagine that the OS scheduler moves Thread A to the CPU core previously used by Thread B. Thread A proceeds to read the shared variable again. Given that the last read on this CPU core yielded a value of 1, the L1 cache on this core might still contain the stale value of 1.
This leads to an unusual situation: from Thread A's perspective, the value has unexpectedly reverted to its previous state.
Is such a scenario plausible, especially on CPUs based on the ARM architecture?
If that scenario were realistic...Nope! Jeremy Friesner is right. I was wrong. What is "realistic" does not matter. What matters is
If all three of those conditions are met, then the behavior of the program is undefined. What is or is not "realistic" is beside the point. Maybe knowing what is or is not "realistic" might be of some use if you've been assigned to analyze a crash dump and satisfy some micro-manager who demands to know precisely what went wrong, but if you're trying to predict how the program will behave in the future, it's undefined. End of story.