Зачем мне барьер памяти?

C # 4 в двух словах (настоятельно рекомендуется кстати) использует следующий код для демонстрации концепции MemoryBarrier (предполагая, что A и B выполнялись в разных потоках):

class Foo{
  int _answer;
  bool complete;
  void A(){
    _answer = 123;
    Thread.MemoryBarrier(); // Barrier 1
    _complete = true;
    Thread.MemoryBarrier(); // Barrier 2
  }
  void B(){
    Thread.MemoryBarrier(); // Barrier 3;
    if(_complete){
      Thread.MemoryBarrier(); // Barrier 4;
      Console.WriteLine(_answer);
    }
  }
}

они упоминают, что барьеры 1 и 4 предотвращают этот пример из записи 0 и барьеров 2 и 3 обеспечивает гарантию свежести : они гарантируют, что если B бежит за A, чтение _complete даст оценку true .

Я не совсем понял. Я думаю, я понимаю, почему барьеры 1 и 4 необходимы: мы не хотим, чтобы запись в _answer была оптимизирована и помещена после записи в _complete (барьер 1), и нам нужно чтобы убедиться, что _answer не кэшируется (Барьер 4). Я также думаю, что понимаю, почему необходим барьер 3: если A запускается только после записи _complete = true , B все равно потребуется обновить _complete , чтобы прочитать правильное значение.

Я не понимаю, зачем нам Барьер 2! Часть меня говорит, что это s потому что, возможно, поток 2 (запущенный B) уже выполнялся до (но не включая) if (_complete) , и поэтому нам нужно убедиться, что _complete обновлено.

Однако я не понимаю, как это помогает. Возможно ли, что для _complete будет установлено значение true в A, но метод B увидит кэшированную (ложную) версию _complete ? То есть, если поток 2 запускал метод B до тех пор, пока после первого MemoryBarrier, а затем поток 1 не выполнял метод A до _complete = true , но не дальше, а затем поток 1 возобновил и протестировал if (_complete) - может ли это , если не приведет к ложному ?