Летучий против блокировки и блокировки

EDIT: Как отмечалось в комментариях, в эти дни я с удовольствием использую Interlocked для случаев с одной переменной, где это очевидно. Когда это усложняется, я все равно вернусь к блокировке...

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

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

"volatile" не заменяет Interlocked.Increment! Он просто гарантирует, что переменная не кэшируется, а используется напрямую.

Приращение переменной требует фактически трех операций:

• прочитать
• приращение
• записи

Interlocked.Increment выполняет все три части как одну атомную операцию.

Либо блокировка, либо блокировка приращения - это то, что вы ищете.

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

например.

while (m_Var)
{ }

Если m_Var установлен в false в другом потоке, но он не объявлен как volatile, компилятор может сделать его бесконечным циклом (но это не значит, что он всегда будет), заставив его проверить регистр CPU (например, EAX потому что это то, с чего m_Var был загружен с самого начала) вместо того, чтобы выдавать другое чтение в ячейку памяти m_Var (это может быть кэшировано - мы не знаем и не заботимся и что точка кеширования когерентности x86/x64). Все сообщения ранее другими, которые упомянули переупорядочение команд, просто показывают, что они не понимают архитектуры x86/x64. Волатильность не устраняет барьеры чтения/записи, как это было в предыдущих сообщениях, в которых говорится, что "это предотвращает переупорядочение". На самом деле, еще раз спасибо протоколу MESI, мы гарантируем, что результат, который мы читаем, всегда одинаковый для всех ЦП независимо от того, были ли фактические результаты удалены в физическую память или просто находятся в локальном кэше ЦП. Я не буду заходить слишком далеко в подробности этого, но будьте уверены, что если это пойдет не так, Intel/AMD, скорее всего, выйдут из памяти процессора! Это также означает, что нам не нужно заботиться о том, чтобы не выполнить заказ. Результаты всегда гарантированно уходят в отставку, иначе мы будем набиты!

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

При использовании volatile вы все равно получите всего 1 инструкцию (при условии, что JIT эффективен, как и должен) - inc dword ptr [m_Var]. Однако процессор (cpuA) не запрашивает эксклюзивное владение линией кэша, делая все, что он сделал с заблокированной версией. Как вы можете себе представить, это означает, что другие процессоры могут записать обновленное значение обратно в m_Var после его чтения cpuA. Поэтому вместо того, чтобы теперь увеличивать значение дважды, вы получаете только один раз.

Надеемся, что это устранит проблему.

Для получения дополнительной информации см. "Понять влияние методов с низким уровнем блокировки в многопоточных приложениях" - http://msdn.microsoft.com/en-au/magazine/cc163715.aspx

p.s. Что вызвало этот очень поздний ответ? Все ответы были настолько откровенно неправильными (особенно отмеченными как ответ) в их объяснении, и я просто должен был прояснить это для всех, кто читал это. пожимает

p.p.s. Я предполагаю, что цель - x86/x64, а не IA64 (у нее другая модель памяти). Обратите внимание, что спецификации Microsoft ECMA ограничены тем, что он определяет самую слабую модель памяти, а не самую сильную (всегда лучше указывать против самой сильной модели памяти, поэтому она совместима между платформами - иначе код, который будет работать 24-7 на x86/x64 может вообще не работать на IA64, хотя Intel реализовала аналогичную сильную модель памяти для IA64) - Microsoft признала это сама - http://blogs.msdn.com/b/cbrumme/archive/2003/05/17/51445.aspx.

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

Я бы сказал, что вы всегда должны отдавать предпочтение блокировке и приращению.

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

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

http://www.ddj.com/hpc-high-performance-computing/210604448

lock (...) работает, но может блокировать поток и может вызвать тупик, если другой код использует одни и те же блокировки несовместимым образом.

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

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

Я второй Jon Skeet ответим и хочу добавить следующие ссылки для всех, кто хочет узнать больше о "volatile" и Interlocked:

Атоматичность, волатильность и неизменность разные, часть первая - (Эрик Липперт Fabulous Adventures In Coding)

Атомность, волатильность и неизменность разные, часть вторая

Атомность, волатильность и неизменность различны, часть третья

Sayonara Volatile - (моментальный снимок машины Joe Duffy Weblog, как он появился в 2012 году)

Я сделал несколько тестов, чтобы увидеть, как работает теория: kenneспасибоu.blogspot.com/2009/05/interlocked-vs-monitor-performance.html. Мой тест был более сосредоточен на CompareExchnage, но результат для Increment аналогичен. В среде с несколькими процессорами блокировка не требуется быстрее. Вот результат теста для Increment на 2-летнем 16-процессорном сервере. Не забывайте, что тест также включает в себя безопасное чтение после увеличения, что типично в реальном мире.

D:\>InterlockVsMonitor.exe 16
Using 16 threads:
          InterlockAtomic.RunIncrement         (ns):   8355 Average,   8302 Minimal,   8409 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):   7077 Average,   6843 Minimal,   7243 Maxmial

D:\>InterlockVsMonitor.exe 4
Using 4 threads:
          InterlockAtomic.RunIncrement         (ns):   4319 Average,   4319 Minimal,   4321 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):    933 Average,    802 Minimal,   1018 Maxmial

Прочтите ссылку Threading in С#. Он охватывает все аспекты вашего вопроса. Каждый из трех имеет разные цели и побочные эффекты.

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

Ключевое слово volatile можно применить к полям этих типов:

• Типы ссылок.
• Типы указателей (в небезопасном контексте). Обратите внимание, что хотя сам указатель может быть изменчивым, объект, на который указывает указывает, не может. Другими словами, вы не можете объявить "указатель на volatile".
• Простые типы, такие как sbyte, byte, short, ushort, int, uint, char, float и bool.
• Тип перечисления с одним из следующих базовых типов: byte, sbyte, short, ushort, int или uint.
• Параметры типового типа, известные как ссылочные типы.
• IntPtr и UIntPtr.

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