Летучие и Thread.MemoryBarrier в C#

Question

Чтобы реализовать блокировки свободного кода для многопоточного приложения я использовал volatile переменные, Теоретически: volatile ключевое слово просто используется, чтобы убедиться, что все потоки увидеть самую последнюю величину а изменчивая переменная; поэтому, если поток A обновляет значение переменной и поток B читает эту переменную сразу после этого обновления, он увидит самое обновленное значение, которое недавно было написано из потока A. Как я читал в C# 4.0 в двух словах книга, которая это неправильно потому

применения летучий не препятствует записи, за которым следует читать из быть обменены.

Может эта проблема решается путем ввода Thread.MemoryBarrier() перед каждым ГЭТ в volatile переменной как:

private volatile bool _foo = false; 

private void A() 
{ 
    //… 
    Thread.MemoryBarrier(); 
    if (_foo) 
    { 
     //do somthing 
    } 
} 

private void B() 
{ 
    //… 
    _foo = true; 
    //… 
} 

И если это решает проблему; рассмотрим, что у нас есть цикл while, который зависит от этого значения в одном из его условий; ставит Thread.MemoryBarrier() до того, как цикл while является правильным способом исправить проблему? Пример:

private void A() 
{ 
    Thread.MemoryBarrier(); 
    while (_someOtherConditions && _foo) 
    { 
     // do somthing. 
    } 
} 

Чтобы быть более точным, я хочу, чтобы переменная _foo дать свою самую свежую ценность, когда любой поток с просьбой к нему в любое время; так что если вставить Thread.MemoryBarrier() перед вызовом переменной исправляет проблему, то я мог бы использовать Foo собственность вместо _foo и сделать Thread.MemoryBarrier() в ГЭТ этой собственности, как:

Foo 
{ 
    get 
    { 
     Thread.MemoryBarrier(); 
     return _foo; 
    } 
    set 
    { 
     _foo = value; 
    } 
} 

Answer 1

«C# В двух словах» правильный, но его утверждение является спорным. Зачем?

• A «запись» сопровождаемая «читать», withot «летучие», гарантированно происходит в программе порядка в любом случае , если это влияет логик в одном потоке
• «Запись» перед «читать» в многопоточной программе совершенно бессмысленно беспокоиться в вашем примере.

Давайте уточним. Возьмите исходный код:

private void A() 
{ 
    //… 
    if (_foo) 
    { 
     //do something 
    } 
} 

Что произойдет, если планировщик потоков уже проверил переменную _foo, но она будет приостановлена ​​как раз перед //do something комментарием? Ну, в этот момент ваш другой поток может изменить значение _foo, а это значит, что все ваши летучие и Thread.MemoryBarriers ничего не посчитали !!! Если абсолютно необходимо избегать do_something, если значение _foo неверно, тогда у вас нет выбора, кроме как использовать блокировку.

Однако, если это нормально для do something для выполнения, когда вдруг _foo становится фальшивым, значит, ключевое слово volatile было более чем достаточно для ваших нужд.

Чтобы быть ясным: все респонденты, которые говорят вам использовать барьер памяти, являются неправильными или обеспечивают излишнюю реакцию.

Answer 2

В вашем втором примере, вам нужно будет также положить a Thread.MemoryBarrier(); внутри цикла, чтобы убедиться, что вы получаете последнее значение каждый раз, когда вы проверяете условие цикла.

Answer 3

Вытащил из here ...

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.

Так что, если мы вернемся к вашему обхвату примеру ... это то, как он должен выглядеть ...

собственных слова

private void A() 
{ 
    Thread.MemoryBarrier(); 
    while (_someOtherConditions && _foo) 
    { 
     //do somthing 
     Thread.MemoryBarrier(); 
    } 
} 

Answer 4

от Microsoft на барьерах памяти: требуется

MemoryBarrier только на многопроцессорные системы со слабым упорядочением памяти (например, система, использующая несколько процессоров Intel Itanium).

Для большинства целей оператор C# блокировки, оператор Visual Basic SyncLock или класс Monitor предоставляют более простые способы синхронизации данных.

Answer 5

Книга .
Модель памяти CLR указывает, что операции загрузки и хранения могут быть переупорядочены. Это относится к нестабильным переменным и.

Объявление переменной как volatile означает только то, что операции загрузки будут иметь приобретают семантики, и хранить операции будут иметь релиз семантику. Кроме того, компилятор избегает выполнения определенных оптимизаций, которые ретранслируют по тому факту, что к переменной обращаются в сериализованном однопоточном режиме (например, подъемная нагрузка/сохранение из циклов).

Использование ключевого слова volatile не создает критические разделы, и это не приводит к тому, что потоки магически синхронизируются друг с другом.

Вы должны быть чрезвычайно осторожно, когда вы пишете свободный код. В этом нет ничего простого, и даже у экспертов есть проблемы, чтобы все исправить.
Независимо от исходной проблемы, которую вы пытаетесь решить, вполне вероятно, что существует гораздо более разумный способ сделать это.