Здравствуйте, ·, Вы писали:
_>>4 (главное — надеюсь хотя сейчас до тебя это дойдёт). Когда ты где-то видишь фразу типа того что атомарность sig_atomic (читай int'а) является достаточной для сигналов, но недостаточной для потоков, то это идёт речь об атомарности в широком смысле (включая гарантии отсутствия переупорядочивания инструкций, который даёт std::atomic с дефолтными настройками). Если же говорить об атомарности в чистом виде (именно в таком мы её и обсуждали, причём по именно твоему определению), то никакой разницы между сигналами, потоками или чем-то ещё просто нет. Ну и да, sig_atomic + вызов atomic_thread_fence(memory_order_seq_cst) при каждом обращение даст тебе атомарность даже в широком смысле (и для сигналов и для потоков), но это к теме нашей дискуссии уже не относится. ·>Напоминаю. Разговор начался с твоего кода присвоения "int global_var" и мой тезис был с "Если это же сделать многопоточным, т.е. эту global_var будут пытаться писать одновременно разные потоки без всякой синхронизации, то возможен data race и значение global_var может быть каким угодно."
Да, всё верно. И я по прежнему утверждаю, что ты тогда сказал чушь, и значение global_var в том коде будет вполне определённым (одним из двух) даже в случае многопоточности.
·>Потом ты начал подменять тезис, изменяя int на sig_atomic, потом ещё volatile, потом маш-коды, теперь ты наконец-то дошел до atomic_thread_fence. Похоже, ты во всём разобрался. Можно сворачивать разговор.
— sig_atomic — это typedef int
— volatile в том примере кода был не нужен, т.к. не было мест, где компилятор мог бы применить опасную оптимизацию
— atomic_thread_fence в том примере кода не нужен, т.к. вообще нет обращения к другим областям памяти
