MS docs ne sont jamais grand, et celui-ci est un bon exemple. Il y a 2 parties à l'_ReadWriteBarrier:
- dire la CPU à faire une barrière de mémoire (c.-à-mfence),
- dire au compilateur de ne pas optimiser autour de la barrière.
Je soupçonne que la partie de l'arbre d'appel fait référence à # 2. à-dire:
int x = 0;
void foo()
{
x = 7;
_ReadWriteBarrier();
x = 8;
}
Sans la barrière, x = 7 peut être complètement supprimé par le compilateur. Avec la barrière, il reste.
Maintenant, qu'en est-une fonction appelle foo?
void bar()
{
x = 3; // optimized away?
foo();
x = 4;
}
Je pense que dans le passé x = 3 aurait pu être optimisé loin (ce qui peut être difficile pour le compilateur de dire si c'est permis ou non), mais maintenant ce sera bien garder les x = 3 instructions.
Je pense.