Гарантируют ли изменчивые переменные в C / C ++ последовательной семантикой между потоками?

Это будет зависеть от вашей архитектуры. Хотя требовать явного сброса кеша или синхронизации памяти для обеспечения того, чтобы записи в память были видны другим потокам, это необычно, ничто не препятствует этому, и я определенно сталкивался с платформами (включая устройство на базе PowerPC, для которого я сейчас разрабатываю), где явные инструкции должны быть выполнены, чтобы гарантировать сброс состояния.

Обратите внимание, что примитивы синхронизации потоков, такие как мьютексы, будут выполнять необходимую работу по мере необходимости, но обычно вам не нужен примитив синхронизации потоков, если все, что вам нужно, это убедиться, что состояние отображается, не заботясь о согласованности - просто инструкция синхронизации / сброса будет хватит.

РЕДАКТИРОВАТЬ: всем, кто все еще не понимает ключевого слова volatile - volatile гарантирует, что компилятор не будет генерировать код, который явно кэширует данные в регистрах, но это НЕ то же самое, что иметь дело с оборудованием, которое прозрачно кэширует / переупорядочивает читает и пишет. Прочтите, например, это или this, или эта статья доктора Доббса или ответ на этот SO вопрос, или просто выберите свой любимый компилятор, нацеленный на слабо согласованную архитектуру памяти, такую ​​как Cell, напишите тестовый код и сравните, что компилятор генерирует то, что вам нужно, чтобы гарантировать, что записи будут видны другим процессам.

Если я правильно понял соответствующие разделы, C ++ 0X не будет гарантировать его для автономной переменной или даже для изменчивой (volatile не предназначен для этого использования), но представит атомарные типы, для которых у вас будет гарантия. (см. заголовок <atomic>).

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

Поскольку вы явно говорите «без мьютексов», pthreads не применяется.

Кроме того, поскольку C ++ не имеет модели памяти, это зависит от архитектуры оборудования.

Это потенциальная гонка за данными.

Что касается потока POSIX, это UB. Я считаю, что то же самое и с C ++.

На практике я не могу представить, как это могло случиться.

Гарантированно ли завершение потока 2 в конечном итоге? Или он может вращаться вечно, потому что когерентность кеша никогда не срабатывает и делает назначение видимым в кэше потока 2?

Если переменная не является изменчивой, у вас нет никаких гарантий. До C ++ 0x в стандарте просто нечего сказать о потоках, и, поскольку переменная не является изменчивой, чтение / запись не считаются наблюдаемыми побочными эффектами, поэтому компилятору разрешено обмануть. После C ++ 0x это состояние гонки, которое явно указано как неопределенное поведение.

Если переменная является изменчивой, вы получаете гарантию, что чтение / запись будут выполняться, и что компилятор не будет переупорядочен по отношению к другим доступам к энергозависимой памяти. (Однако это само по себе не гарантирует, что ЦП не переупорядочит эти обращения к памяти - просто компилятор этого не сделает)

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

Так что нет вообще, корректная работа не гарантируется даже с volatile. Может и, вероятно, часто будет, но не всегда (и это зависит от того, что происходит после цикла). Это зависит от того, насколько далеко компилятор готов зайти в оптимизации. Но разрешено зайти достаточно далеко, чтобы взломать код. Так что не надейтесь на это. Если вы хотите синхронизировать что-то подобное, используйте барьеры памяти. Вот для чего они нужны. (И если вы сделаете это, вам больше не понадобится volatile)

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

Но, честно говоря, проводить опрос в ожидании события - это действительно плохой стиль. Даже если вы сделаете yield, ваш процесс будет снова и снова переноситься без каких-либо действий.

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