поэтому у меня логический тип в C ++ на многопроцессорной машине.Переменная запускает жизнь как true, а затем есть несколько потоков, любой из которых или более может записать ее как false.
В то же время эти потоки могут также прочитать эту переменную, чтобы проверить еегосударство.Мне все равно, синхронизируется ли чтение этой переменной с какой-либо из записей, каждая из которых происходит в разных местах кода, и не имеет значения, происходит ли она до или после какой-либо конкретной записи.Теперь, нужна ли мне блокировка для этого логического значения?
Единственный способ, которым мне понадобится блокировка, - это если на очень низком уровне память может быть повреждена двумя конкурирующими операциями записи.Если, например, инструкция по сборке на процессоре A записывает 0 в байт, который представляет логическое значение, в то время как процессор B делает то же самое ... и вместо записи 0, память заканчивается значением 22 иличто-то.Это может что-то испортить.
Итак, как правило, если proc A записывает 3 в ячейку памяти, а proc B записывает 7 без синхронизации, гарантированно ли я получу по крайней мере 3 или 7?Или это так просто сломать память?
Редактировать:
Спасибо за комментарии, ребята.Немного больше информации: в программе есть синхронизация.Подводя итог, можно сказать, что рассматриваемый флаг указывает, является ли определенный пул памяти «грязным» (необходимо сжать).Следовательно, любой поток может принять решение установить этот флаг в false (что означает, что пул грязный).Например, освобождение памяти из пула делает ее грязной.Затем любой поток может также прочитать этот флаг и установить другой флаг, чтобы сигнализировать о необходимости очистки - эта проверка выполняется, когда память выделяется из пула, очистка сигнализируется, если у нас недостаточно памяти.Где-то в моем главном критическом разделе между итерациями, где каждый поток ищет дополнительные данные для обработки, я сделаю так, чтобы потоки проверили этот второй флаг и сделали что-то подходящее, чтобы убедиться, что: все остальные команды завершают свою текущую итерацию, один потокочищает память, устанавливает первый флаг обратно в значение true (поскольку пул не является грязным), устанавливает второй флаг обратно в значение false, а затем снова освобождает все потоки.
Так что я не думаю, что янужна блокировка, потому что: блокировка гарантирует, что запись не произойдет одновременно с другой записью или чтением.Но кого это волнует, до тех пор, пока аппаратное обеспечение не подведет меня, наихудший сценарий - случайное чтение до или после записи - это то же самое, что произошло бы, если бы я защитил его с помощью блокировки,только тогда мы действительно были бы уверены, что это было до или после ...
Я думаю, что тот же аргумент применим ко второму флагу, который я упомянул выше.