Попытка понять функции Interlocked *
Это касается только реализации, специфичной для Microsoft / Visual Studio и Intel / AMD.
Скажем, если объявить глобальную переменную:
volatile __declspec(align(16)) ULONG vFlags = 0;
И, скажем, у меня есть несколько конкурирующих потоков:
//Thread 1
ULONG prevFlags;
prevFlags = InterlockedExchange(&vFlags, 0);
if (prevFlags != 0)
{
//Do work
}
а затем из других тем я делаю:
//Thread N
vFlags = SomeNonZeroValue;
Так, скажем, в многопроцессорной системе в тот момент, когда thread 1 выполняет заблокированную инструкцию InterlockedExchange, некоторые другие потоки приступают к выполнению инструкций vFlags = 2 и vFlags = 4.
Что будет в таком случае? Будут ли vFlags = 2 и vFlags = 4 останавливаться до завершения работы InterlockedExchange или игнорировать эту блокировку?
Или мне нужно использовать это вместо этого?
//Thread N
InterlockedOr(&vFlags, SomeNonZeroValue);
@zerkms не могли бы вы дать дополнительную информацию о том, что такое memory barriers?
@zerkms: Спасибо. Хорошая статья. Согласно ему, Microsoft Блокируемые функции реализует эти ограждения.
Заблокирован действительно был бы, но vFlags = SomeNonZeroValue; - нет.
@zerkms Даже если vFlags = SomeNonZeroValue; вызывается из другой ветки? Разве эти барьеры памяти не имеют значения для смежного использования этих переменных, иначе они будут сброшены при переключении контекста? Также. Я проверил, и InterlockedOr просто компилируется в инструкцию lock OR [mem], reg на процессоре Intel, а InterlockedExchange просто в инструкцию XCHG [mem], reg. Даже с префиксом lock.
Тем более, что он запускается из другого потока. Учитывая, что vFlags = SomeNonZeroValue; поставляется без барьеров памяти - не гарантируется, что это изменение когда-либо распространится, и наоборот. Барьеры памяти идут попарно с обеих сторон.
Ответы 1
Инструкции, которые не используют блокировки для обновления переменной, не взаимодействуют с инструкциями, которые это делают. Блокировка - это совместный процесс, который должны соблюдать все участники, чтобы он работал. Итак, да, обновление флага простым назначением в одном потоке не будет заблокировано другим потоком, вызывающим InterlockedExchange.
С другой стороны, присвоение разных значений переменным, которые считываются другими потоками, поднимает проблему видимости между ядрами, поскольку другие потоки могут не сразу или даже никогда не увидеть обновления. InterlockedExchange также решает эту проблему, обеспечивая неявные ограждения памяти.
В заключение я бы использовал InterlockedExchange во всех потоках, обновляющих флаг.
Я предполагаю, что InterlockedOr попадает в ту же категорию, верно?
@MikeF: Да, на самом деле MSDN говорит: The interlocked functions provide a simple mechanism for synchronizing access to a variable that is shared by multiple threads. This function is atomic with respect to calls to other interlocked functions.
Если у вас нет барьеров памяти / синхронизации - потоки не гарантируют, что когда-либо увидят изменения.