275 page item 40 :
scenemanager's mRequestType depend on order for thread safe.As a general rule, compilers are permitted to
reorder such unrelated assignments. That is, given this sequence of assignments
(where a, b, x, and y correspond to independent variables),
a = b;
x = y;
compilers may generally reorder them as follows:
x = y;
a = b;
Even if compilers don’t reorder them, the underlying hardware might do it (or might
make it seem to other cores as if it had), because that can sometimes make the code
mRequestType need declaire volatile???
oops ,i check more
volatile can't solve order , too
only solution is std::std::atomic ............
declaring valAvailable as std::atomic ensures that our crit‐
ical ordering requirement—imptValue must be seen by all threads to change no later
than valAvailable does—is maintained.
Declaring valAvailable as volatile doesn’t impose the same code reordering
volatile bool valAvailable(false);
auto imptValue = computeImportantValue();
valAvailable = true; // other threads might see this assignment
// before the one to imptValue!
Here, compilers might flip the order of the assignments to imptValue and valAvail
able, and even if they don’t, they might fail to generate machine code that would
prevent the underlying hardware from making it possible for code on other cores to
see valAvailable change before imptValue.
These two issues—no guarantee of operation atomicity and insufficient restrictions
on code reordering—explain why volatile’s not useful for concurrent program‐
ming, but it doesn’t explain what it is useful for. In a nutshell, it’s for telling compilers
that they’re dealing with memory that doesn’t behave normally.