Как _ReadWriteBarrier распространяется по дереву вызовов? - PullRequest
Новая
       51

Как _ReadWriteBarrier распространяется по дереву вызовов?

2 голосов
/ 28 января 2010

Я просматриваю этот фрагмент текста в документации для встроенной функции Visual C ++ _ReadWriteBarrier:

В прошлых версиях Visual C ++ компилятор, _ReadWriteBarrier и Функции _WriteBarrier применялись только локально и не влияли функционирует до дерева вызовов. В визуальном C ++ 2005 и выше, эти функции соблюдаются все пути до вызова дерево.

Я понимаю, что делает барьер внутри функции, но «вверх по дереву вызовов», по-видимому, означает, что функция foo(), вызывающая функцию bar(), может знать, содержит ли bar() барьер или нет. Что на самом деле изменилось в VC2005, чтобы включить это ... соглашение о вызовах / ABI, некоторый глобальный анализ, выполненный компилятором, или что?

1 Ответ

1 голос
/ 29 января 2010

Документы MS никогда не бывают хорошими, и этот пример тому хороший. В _ReadWriteBarrier есть две части:

  1. говорит процессору сделать барьер памяти (т.е. mfence),
  2. говорит компилятору не оптимизировать вокруг барьера.

Я подозреваю, что часть дерева вызовов относится к # 2. то есть: 

int x = 0;

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

Без барьера компилятор может полностью удалить x = 7. С барьером это остается. А как насчет функции, которая вызывает foo? 

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

Я думаю, что в прошлом x = 3 мог быть оптимизирован (что может быть трудно для компилятора, определить, разрешено это или нет), но теперь он будет правильно выполнять инструкции x = 3.

Я думаю.

...