Come fa _ReadWriteBarrier propaga l'albero chiamata?

Question

sto guardando questo po 'di testo nel documentazione per Visual C ++ 's _ReadWriteBarrier intrinseca:

  

Nelle versioni precedenti di Visual C ++   compilatore, il _ReadWriteBarrier e   _WriteBarrier funzioni sono state applicate solo a livello locale e non hanno influenzato   funzioni l'albero chiamata. in Visual   C ++ 2005 e versioni successive, queste funzioni   sono applicate tutta la strada fino alla chiamata   albero.

Capisco quello che la barriera fa all'interno di una funzione, ma il "l'albero chiamata" sembra implicare che una funzione foo() chiamata di una funzione bar() può sapere se bar() contiene una barriera o meno. Che cosa realmente cambiato nella VC2005 per attivare questo ... la convenzione di chiamata / ABI, alcune analisi globale fatta dal compilatore, o cosa?

Answer 1

documenti MS sono mai grandi, e questo è un buon esempio di questo. Ci sono 2 parti al _ReadWriteBarrier:

1. dicendo la CPU per fare una barriera di memoria (cioè mfence),
2. dice il compilatore non ottimizzare attorno alla barriera.

Ho il sospetto che la parte dell'albero chiamata si riferisce a # 2. vale a dire:

int x = 0;

void foo()
{
   x = 7;
   _ReadWriteBarrier();
   x = 8;
}

Senza la barriera, x = 7 può essere completamente rimosso dal compilatore. Con la barriera, rimane. Ora, che dire di una funzione che chiama pippo?

void bar()
{
   x = 3;  // optimized away?
   foo();
   x = 4;
}

Credo che in passato x = 3 potrebbe essere stato ottimizzato di distanza (che può essere difficile per il compilatore a dire se che è permesso o no), ma ora sarà correttamente mantenere i x = 3 istruzioni.

Credo.