Использует ли Interlocked.CompareExchange барьер памяти?

Любая инструкция x86 с префиксом lock имеет барьер полной памяти. Как показано в ответе Абеля, API-интерфейсы Interlocked * и CompareExchanges используют инструкцию с префиксом lock, такую ​​как lock cmpxchg. Значит, подразумевается забор памяти.

Да, Interlocked.CompareExchange использует барьер памяти.

Почему? Потому что это сделали процессоры x86. Из Тома 3A: Руководство по системному программированию, часть 1, раздел 7.1.2.2. :

Для процессоров семейства P6 заблокированные операции сериализуют все невыполненные операции загрузки и сохранения (то есть дождаться их завершения). Это правило также справедливо для процессоров Pentium 4 и Intel Xeon, за одним исключением. Операции загрузки, которые ссылаются на слабо упорядоченные типы памяти (такие как тип памяти WC), не могут быть сериализованы.

volatile не имеет никакого отношения к этому обсуждению. Речь идет об атомарных операциях; для поддержки атомарных операций в ЦП x86 гарантирует выполнение всех предыдущих загрузок и сохранений.

ref не соблюдает обычные volatile правила, особенно в таких вещах, как:

volatile bool myField;
...
RunMethod(ref myField);
...
void RunMethod(ref bool isDone) {
    while(!isDone) {} // silly example
}

Здесь RunMethod не гарантирует обнаружение внешних изменений в isDone, даже если базовое поле (myField) равно volatile; RunMethod не знает об этом, поэтому у него нет правильного кода.

Тем не мение! Это не должно быть проблемой:

• если вы используете Interlocked, используйте Interlocked для всего доступа к полю
• если вы используете lock, используйте lock для всего доступа к полю

Следуйте этим правилам, и все должно работать нормально.

Повторите редактирование; да, это поведение является важной частью Interlocked. Честно говоря, я не знаю, как это реализовано (барьер памяти и т. Д. - обратите внимание, что это методы "InternalCall", поэтому я не могу проверить ;-p) - но да: обновления из одного потока будут немедленно видны для все остальные до тех пор, пока они используют Interlocked методы (отсюда и моя точка зрения выше).

Кажется, есть какое-то сравнение с одноименными функциями Win32 API, но этот поток посвящен классу C # Interlocked. Из самого его описания гарантируется, что его операции атомарны. Я не уверен, как это переводится в «полные барьеры памяти», как упоминалось в других ответах здесь, но судите сами.

В однопроцессорных системах ничего особенного не происходит, есть всего одна инструкция:

FASTCALL_FUNC CompareExchangeUP,12
        _ASSERT_ALIGNEDInterlockedX86 ecx
        mov     eax, [esp+4]    ; Comparand
        cmpxchg [ecx], edx
        retn    4               ; result in EAX
FASTCALL_ENDFUNC CompareExchangeUP

Но в многопроцессорных системах аппаратная блокировка используется для предотвращения одновременного доступа к данным другим ядрам:

FASTCALL_FUNC CompareExchangeMP,12
        _ASSERT_ALIGNEDInterlockedX86 ecx
        mov     eax, [esp+4]    ; Comparand
  lock  cmpxchg [ecx], edx
        retn    4               ; result in EAX
FASTCALL_ENDFUNC CompareExchangeMP

Интересно прочитать кое-где некоторые неправильные выводы, но в целом отличный по этому поводу - это сообщение в блоге на CompareExchange.

Обновление для ARM

Как часто бывает, ответ будет: «в зависимости от обстоятельств». Похоже, что до 2.1 ARM имела полубарьер. В версии 2.1 это поведение было изменено на полный барьер для Interlocked операций.

Текущий код можно найти на странице и фактическая реализация CompareExchange здесь. Обсуждения сгенерированной сборки ARM, а также примеры сгенерированного кода можно увидеть в вышеупомянутом PR.

MSDN говорит о функциях Win32 API: " Большинство взаимосвязанных функций обеспечивают полную защиту памяти на всех платформах Windows "

(исключение составляют функции Interlocked с явной семантикой Acquire / Release)

Исходя из этого, я мог бы сделать вывод, что среда выполнения C # Interlocked дает те же гарантии, поскольку они задокументированы с идентичным во всем остальном поведением (и они разрешаются к внутренним операторам ЦП на платформах, которые я знаю). К сожалению, из-за того, что MSDN часто размещает образцы вместо документации, это явно не прописано.

Связанные функции гарантированно остановят шину и процессор, пока он разрешает операнды. Непосредственным следствием этого является то, что никакое переключение потоков на вашем или другом процессоре не прервет заблокированную функцию в середине ее выполнения.

Поскольку вы передаете ссылку на функцию C #, базовый код ассемблера будет работать с адресом фактического целого числа, поэтому доступ к переменной не будет оптимизирован. Он будет работать именно так, как ожидалось.

edit: Вот ссылка, которая лучше объясняет поведение инструкции asm: http://faydoc.tripod.com/cpu/cmpxchg.htm
Как видите, шина останавливается из-за принудительного цикла записи, поэтому любые другие «потоки» (читай: другие ядра процессора), которые будут пытаться использовать шину при этом будут помещены в очередь ожидания.

Согласно ECMA-335 (раздел I.12.6.5):

5. Явные атомарные операции. Библиотека классов предоставляет множество атомарных операций в классе System.Threading.Interlocked. Эти операции (например, Increment, Decrement, Exchange и CompareExchange) выполняют неявные операции получения / освобождения.

Итак, эти операции следуют принципу наименьшего удивления.