Является ли слово «volatile» все еще сломанным в C#?

Question

Joe Albahari имеет great series на многопоточности, который должен быть прочитан и должен быть известен наизусть для всех, кто выполняет многопоточность C#.

В части 4, однако он упоминает о проблемах с летучим:

Обратите внимание, что применение летучего не препятствует записи с последующим чтением от быть обменены, и это может создать задачки. Joe Duffy хорошо иллюстрирует проблему в следующем примере: если Test1 и Test2 работают одновременно на разных потоках, возможно, что a и b оба получат значение 0 (несмотря на использование volatile на как x, так и у)

Вслед за примечанием, что документация MSDN неверно:

в документации MSDN говорится, что использование летучего ключевого слова гарантирует , что наибольшая ценность уточненного присутствует в поле всегда. Это неверно, так как, как мы видели, запись с последующим считыванием может быть изменена на .

Я проверил MSDN documentation, который был последний раз изменялся в 2015 году, но до сих пор списки:

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

Сейчас я до сих пор избежать волатильным в пользу более многословным, чтобы предотвратить темы с использованием устаревших данных:

private int foo; 
private object fooLock = new object(); 
public int Foo { 
    get { lock(fooLock) return foo; } 
    set { lock(fooLock) foo = value; } 
} 

как части о многопоточности были написаны в 2011 году, является аргументом по-прежнему актуальны сегодня? Должен ли волатильность все же избегать любой ценой в пользу блокировок или полных ограждений памяти, чтобы предотвратить очень сложное создание ошибок, которые, как уже упоминалось, даже зависят от поставщика процессора, на котором он работает?

Answer 1

Неустойчивый в своей текущей реализации не сломан, несмотря на то, что в популярных блогах, требующих такой вещи. Это, однако, плохо указано, и идея использования модификатора в поле для указания порядка памяти не так велика (сравните volatile в Java/C# с атомарной спецификацией C++, у которой было достаточно времени, чтобы учиться на более ранних ошибках). С другой стороны, статья MSDN была четко написана кем-то, у кого нет деловых разговоров о параллелизме и является полностью фиктивным. Единственный разумный вариант - полностью игнорировать его.

Летучих гарантии приобретает/отпускание семантики при доступе поля и может быть применено только к типам, которые позволяют атомные читают и пишет. Не больше, не меньше. Этого достаточно для эффективного использования многих алгоритмов без блокировки, таких как non-blocking hashmaps.

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

private int a; 
private volatile bool x; 

public void Publish() 
{ 
    a = 1; 
    x = true; 
} 

public void Read() 
{ 
    if (x) 
    { 
     // if we observe x == true, we will always see the preceding write to a 
     Debug.Assert(a == 1); 
    } 
} 

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

Answer 2

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

Answer 3

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

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

Если вы просто хотите, чтобы ваше имущество имело современное значение, вы должны просто использовать volatile.

Проблема возникает, если вы пытаетесь выполнить несколько параллельных операций, как если бы они были атомарными. Если вам нужно заставить несколько операций быть атомарными вместе, вам нужно заблокировать всю операцию. Рассмотрим пример снова, но с помощью замков:

class DoLocksReallySaveYouHere 
{ 
    int x, y; 
    object xlock = new object(), ylock = new object(); 

    void Test1()  // Executed on one thread 
    { 
    lock(xlock) {x = 1;} 
    lock(ylock) {int a = y;} 
    ... 
    } 

    void Test2()  // Executed on another thread 
    { 
    lock(ylock) {y = 1;} 
    lock(xlock) {int b = x;} 
    ... 
    } 
} 

Замки вызвать может привести к некоторой синхронизации, которая может предотвратить какa и b от того, значение 0 (я не проверил это). Однако, так как x и y запираются самостоятельно, либо a или b еще может недетерминированно в конечном итоге со значением 0.

Таким образом, в случае упаковки изменение одной переменной, вы должны быть безопасными с помощью volatile, и на самом деле не было бы безопаснее использовать lock. Если вам необходимо атомизировать несколько операций, вам нужно использовать lock вокруг всего атомного блока, иначе планирование все равно будет приводить к недетерминированному поведению.