Здравствуйте, alex_public, Вы писали:

_>·>Напоминаю. Разговор начался с твоего кода присвоения "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 в том примере кода не нужен, т.к. вообще нет обращения к другим областям памяти
_>Ещё комментарии будут? )))
atomic_thread_fence упорядочивает не "другие области", а обращения к памяти. Если у тебя более одного обращения из разных тредов, пусть даже к одной области — то у тебя уже могут быть вариации.