Летучий против Блокированный против блокировки

Допустим, у класса есть public int counterполе, доступ к которому осуществляется несколькими потоками. Это intтолько увеличивается или уменьшается.

Чтобы увеличить это поле, какой подход следует использовать и почему?

• lock(this.locker) this.counter++;,
• Interlocked.Increment(ref this.counter);,
• Измените модификатор доступа counterна public volatile.

Теперь, когда я обнаружил volatile, я удалил много lockутверждений и использование Interlocked. Но есть ли причина не делать этого?

Худший (на самом деле не будет работать)

Измените модификатор доступа counterнаpublic volatile

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

Если это не так volatile , и ЦП A увеличивает значение, то ЦП B может фактически не увидеть это увеличенное значение до некоторого времени спустя, что может вызвать проблемы.

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

Второе место:

lock(this.locker) this.counter++;

Это безопасно (при условии, что вы помните, lockгде бы вы ни находились this.counter). Это препятствует тому, чтобы любые другие потоки выполнили любой другой код, который охраняется locker. Использование блокировок также предотвращает проблемы переупорядочения многопроцессорных систем, как описано выше, и это здорово.

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

Лучший

Interlocked.Increment(ref this.counter);

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

Я не совсем уверен, однако, если это обойти другие процессоры, переупорядочивающие вещи, или вам также нужно объединить volatile с приращением.

InterlockedNotes:

1. Взаимосвязанные методы безопасны одновременно на любом количестве ядер или процессоров.
2. Взаимосвязанные методы применяют полную границу вокруг выполняемых инструкций, поэтому изменение порядка не происходит.
3. Методы с блокировкой не нуждаются или даже не поддерживают доступ к изменчивому полю , поскольку volatile размещает половину ограждения вокруг операций на заданном поле, а блокированное использует полное ограждение.

Сноска: Что на самом деле хорошо для изменчивого?

Как volatileне предотвратить такие проблемы многопоточности, для чего это нужно? Хорошим примером является то, что у вас есть два потока, один из которых всегда записывает в переменную (скажем queueLength), а другой всегда читает из этой же переменной.

Если queueLengthон не является энергозависимым, поток A может записывать пять раз, но поток B может видеть, что эти записи задерживаются (или даже могут быть в неправильном порядке).

Решением будет блокировка, но вы также можете использовать volatile в этой ситуации. Это гарантирует, что поток B всегда будет видеть самую последнюю информацию, которую написал поток A. Однако обратите внимание, что эта логика работает, только если у вас есть писатели, которые никогда не читают, и читатели, которые никогда не пишут, и если то, что вы пишете, является атомарной ценностью. Как только вы выполните одну операцию чтения-изменения-записи, вам нужно перейти к блокированным операциям или использовать блокировку.

РЕДАКТИРОВАТЬ: Как отмечено в комментариях, в эти дни я рад использовать Interlockedдля случаев одной переменной, где это, очевидно, хорошо. Когда все станет сложнее, я все равно вернусь к блокировке ...

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

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

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

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

1. читать
2. приращение
3. записывать

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

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

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

например

while (m_Var)
{ }

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

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

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

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

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

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

pps Я предполагаю, что целью является 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

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

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

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

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

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

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

Атомность, изменчивость и неизменность различны, часть первая («Сказочные приключения Эрика Липперта в кодировании»)

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

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

Sayonara Volatile - (снимок Wayback Machine из блога Джо Даффи, как он появился в 2012 году)

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

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

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

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