Неустранимые «флаги» потокобезопасны в C# /. NET?

Question

(Примечание: Я уже задавал этот вопрос, но ответ был специфичным для Java, поэтому я задаю тот же вопрос для C# и .NET framework. Это не дубликат.)

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

public class SampleAsync 
{ 
    public SampleAsync() { } 

    private bool completed; 
    public void Start() 
    { 
     var worker = new BackgroundWorker(); 
     worker.DoWork += (sender, e) => { 
      //... do something on a different thread 
      completed = true; 
     }; 
     worker.RunWorkerAsync(); 
    } 

    public void Update() 
    { 
     if (!completed) return; 
     //... do something else 
    } 
} 

* Пользователь несет ответственность за то, чтобы Start вызывалась только один раз. Update называется везде и где угодно.

Я всегда предполагал, что это потокобезопасно в C#/.NET framework, потому что, хотя ничто не строго синхронизировано, я только установил completed в true. Как только будет наблюдаться true, он не будет сброшен до false. Он инициализируется значением false в конструкторе, который по определению является потокобезопасным (если вы не делаете в нем что-то глупое). Таким образом, безопасно ли использовать потоки с помощью несанкционированных флагов? (И если да, то это даже дает никаких преимуществ производительности?)

Благодарности

Answer 1

Ваш код поточно, потому что bool является атомарным типа.

MSDN:

Чтение и запись следующих типов данных являются атомарными: BOOL, голец, байт, SByte, короткие, USHORT, UINT, INT, поплавок, и ссылочные типы. В дополнение, чтение и запись типов перечислений с базовым типом в , предыдущий список также является атомарным. Считывание и запись других типов, , включая длинные, улоновые, двойные и десятичные, а также определяемые пользователем типы , не гарантируются как атомарные. Помимо библиотеки функций, предназначенных для этой цели, нет гарантии атома read-modify-write, например, в случае приращения или уменьшения.

См: http://msdn.microsoft.com/en-us/library/aa691278(v=vs.71).aspx

Пожалуйста, отметьте ваше поле с volatile:

private volatile bool completed; 

MSDN:

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

См: http://msdn.microsoft.com/en-us/library/x13ttww7(v=vs.71).aspx

Answer 2

Это сильно зависит от целевой архитектуры. У процессоров Intel есть сильная модель памяти, поэтому вы, как правило, избегаете кода. Но тогда дрожь может сильно вас повредить. Например, джиттер x86 может хранить переменную в регистре процессора, особенно когда оператор if() отображается в узком цикле. И это делается только в выпуске Release, потрясающем отладочном кошмаре. Объявление переменной volatile является полосой для этого. Для джиттера x64 это не требуется, по крайней мере, в его текущей версии.Но band-aids, как правило, не останавливают кровотечение на процессорах со слабой моделью памяти, такой как ARM и Itanium. Они, конечно же, не обещают, что обновленное состояние переменной будет видимо в другом потоке в ближайшее время. Планировщик потоков стремится к сбросу кэша процессора. В итоге.

Нет смысла делать это неправильно. Используйте подходящий объект синхронизации, например AutoResetEvent. Или Interlocked.CompareExchange(), если вы беспокоитесь о циклах.