Синхронизация потоков. Как именно блокировка делает доступ к памяти «правильным»?

почему именно lock(ms_Lock) { ms_Counter += 1; } делает программу полностью правильной, а lock(ms_Lock) {}; ms_Counter += 1; только почти правильной?

Хороший вопрос! Ключ к пониманию этого заключается в том, что блокировка выполняет две функции:

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

Я не совсем понимаю, как блокировка некоторого произвольного объекта предотвращает кэширование другой памяти в регистрах / кеш-памяти процессора и т. Д.

Как вы заметили, кэширование памяти в регистрах или кеш-памяти ЦП может вызывать странные вещи в многопоточном коде. (См. Мою статью о волатильности для мягкого объяснения связанной темы..) Вкратце: если один поток делает копию страницы памяти в кэше ЦП до изменения другого потока эта память, а затем первый поток выполняет чтение из кеша, а затем, по сути, первый поток переместил чтение назад во времени. Точно так же записи в память могут казаться перемещенными вперед во времени.

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

Интересный эксперимент - вместо пустой блокировки поместить туда вызов Thread.MemoryBarrier () и посмотреть, что произойдет. Вы получаете такие же результаты или разные? Если вы получите тот же результат, значит, помогает барьер памяти. Если вы этого не сделаете, то тот факт, что потоки почти синхронизируются правильно, - это то, что замедляет их в достаточной степени, чтобы предотвратить большинство гонок.

Я предполагаю, что это последнее: пустые блокировки настолько замедляют потоки, что они не проводят большую часть своего времени в коде, который имеет состояние гонки. Барьеры памяти обычно не требуются для процессоров с сильной моделью памяти. (Вы используете машину x86, Itanium или что-то еще? Машины x86 имеют очень сильную модель памяти, Itanium имеют слабую модель, которая требует барьеров памяти.)

Вы не говорите, сколько потоков вы использовали, но я предполагаю, что два - если вы работали с четырьмя потоками, я бы ожидал, что разблокированная версия завершится с результатом, который достаточно близок к 1/4 от однопоточной версии «правильный» результат.

Когда вы не используете lock, ваша четырехпроцессорная машина выделяет поток каждому ЦП (это утверждение не учитывает присутствие других приложений, которые также будут запланированы по очереди, для простоты), и они будут работать на полной скорости, без вмешательства в друг с другом. Каждый поток получает значение из памяти, увеличивает его и сохраняет обратно в память. Результат перезаписывает то, что там есть, а это означает, что, поскольку у вас есть 2 (или 3, или 4) потока, работающие на полной скорости одновременно, некоторые из приращений, сделанных потоками на других ваших ядрах, эффективно выбрасываются. Таким образом, ваш окончательный результат ниже, чем у одного потока.

Когда вы добавляете оператор lock, он сообщает CLR (это похоже на C #?), Чтобы гарантировать, что только один поток на любом доступном ядре может выполнить этот код. Это критическое изменение по сравнению с ситуацией выше, поскольку несколько потоков теперь мешают друг другу, хотя, как вы понимаете, этот код не является потокобезопасным (достаточно близко к этому, чтобы быть опасным). Эта неправильная сериализация приводит (как побочный эффект) к тому, что последующее приращение выполняется одновременно реже - поскольку подразумеваемая разблокировка требует дорогостоящего, с точки зрения этого кода и вашего многоядерного процессора, по крайней мере, пробуждения любых потоков, которые были ждем блокировки. Эта многопоточная версия также будет работать медленнее, чем однопоточная версия из-за этих накладных расходов. Потоки не всегда ускоряют код.

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

Ознакомьтесь с классом Interlocked на уровне оборудования для атомарной обработки переменных определенного типа.

Если у вас нет блокировки вокруг общей переменной ms_Sum, тогда оба потока могут получить доступ к переменной ms_Sum и увеличивать значение без ограничений. 2 потока, выполняющиеся параллельно на двухъядерном компьютере, будут одновременно работать с переменной.

Memory: ms_Sum = 5
Thread1: ms_Sum += 1: ms_Sum = 5+1 = 6
Thread2: ms_Sum += 1: ms_Sum = 5+1 = 6 (running in parallel).

Вот приблизительная разбивка событий, которые я могу объяснить:

1: ms_sum = 5.
2: (Thread 1) ms_Sum += 1;
3: (Thread 2) ms_Sum += 1;
4: (Thread 1) "read value of ms_Sum" -> 5
5: (Thread 2) "read value of ms_Sum" -> 5
6: (Thread 1) ms_Sum = 5+1 = 6
6: (Thread 2) ms_Sum = 5+1 = 6

Имеет смысл, что без синхронизации / блокировки вы получите результат примерно вдвое меньше ожидаемого, поскольку 2 потока могут делать что-то «почти» вдвое быстрее.

При правильной синхронизации, то есть lock(ms_Lock) { ms_Counter += 1; }, порядок меняется примерно так:

 1: ms_sum = 5.
 2: (Thread 1) OBTAIN LOCK. ms_Sum += 1;
 3: (Thread 2) WAIT FOR LOCK.
 4: (Thread 1) "read value of ms_Sum" -> 5
 5: (Thread 1) ms_Sum = 5+1 = 6
 6. (Thread 1) RELEASE LOCK.
 7. (Thread 2) OBTAIN LOCK.  ms_Sum += 1;
 8: (Thread 2) "read value of ms_Sum" -> 6
 9: (Thread 2) ms_Sum = 6+1 = 7
10. (Thread 2) RELEASE LOCK.

Что касается того, почему lock(ms_Lock) {}; ms_Counter += 1; "почти" правильно, я думаю, вам просто повезло. Блокировка заставляет каждый поток замедляться и «ждать своей очереди», чтобы получить и снять блокировку. Тот факт, что арифметическая операция ms_Sum += 1; настолько тривиальна (она выполняется очень быстро), вероятно, поэтому результат "почти" нормальный. К тому времени, когда поток 2 выполнил накладные расходы на получение и снятие блокировки, простая арифметика, вероятно, уже выполнена потоком 1, так что вы приблизитесь к желаемому результату. Если бы вы выполняли что-то более сложное (требующее больше времени на обработку), вы бы обнаружили, что это не будет так близко к желаемому результату.

Мы обсуждали это с deafsheep, и нашу текущую идею можно представить в виде следующей схемы

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

где

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

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

Источник существующей ошибки исследуется в этом вопросе :

Вот и ответ.

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

Это связано с синхронизацией кеша ms_sum между двумя потоками. Каждый поток имеет свою кэшированную копию ms_sum.

В вашем 1-м примере, поскольку вы не используете «блокировку», вы оставляете на усмотрение ОС, когда выполнять синхронизацию (когда копировать обновленное значение кеша обратно в основную память или когда чтобы прочитать его из основной памяти в кеш). Итак, каждый поток в основном обновляет свою копию ms_sum. Теперь синхронизация действительно происходит время от времени, но не при каждом переключении контекста потока, что приводит к результату чуть больше 50 000 000. Если бы это происходило при каждом переключении контекста потока, вы бы получили 10 000 000.

В 2-м примере ms_sum синхронизируется на каждой итерации. Это позволяет довольно хорошо синхронизировать ms_sum # 1 и ms_sum # 2. Итак, вы получите почти 10 000 000. Но это не будет полностью до 10 000 000, потому что каждый раз, когда происходит переключение контекста потока, ms_sum может быть отключено на 1, потому что + = происходит за пределами блокировки.

В общем, мне немного неизвестно, какие именно части кешей различных потоков синхронизируются при вызове блокировки. Но из-за вашего результата почти 10 000 000 во втором примере я вижу, что ваш вызов блокировки вызывает синхронизацию ms_sum.