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

>> Наличие барьеров без volatile не гарантирует правильной работы. Наличие volatile без барьеров — тоже не гарантирует. volatile обеспечивает поддержку со стороны языка, барьер — со стороны аппаратуры.

ME>Это ерунда. На POSIX все барьеры работают без volatile. POSIX работает практически на любой архитектуре. Почему это вдруг в vindoze на той же архитектуре понадобились volatile? Ответ один — от недопонимания.

На самом деле мир сложнее.
Библиотеки POSIX — примерно как жены из сказки — умные, хорошие, красивые, но бывают только в книжках, а в жизни совсем не такие. Кроме того, область их применения довольно узка, чтобы рекомендовать их как панацею.
Все уже давно научились обходиться без них и решают свои проблемы самостоятельно.

Вроде ж мы уже договорились, что в тех же Windows и Linux через дельта-т (время до первого прерывания) вторая нить обязательно увидит обновления, сделанные первой нитью. Может подход не слишком академичный, но ведь с volatile сие в любом случае работает. Разумеется, при использовании более сложной схемы обработки нужно использовать либо барьеры либо даже ядреные примитивы синхронизации. Если нужно все сразу, то тут уж ничего не попишешь и нужно делать сброс памяти (те же InterlockedExchange или set_mb), но сие, IMHO, не совсем правильный подход(разве что в исключительных случаях).


>> Зачем, по-твоему, вообще существует volatile? Именно для урезания вольностей оптимизатора в отношении состояния объекта.

ME>volatile был введен в C и на сегодняшний день нужен только для асинхронных обработчиков сигналов. Точка.

Ну не совсем так.
Но, что правда, compiler barrier а-ля линуксового barrier() действительно зачастую использовать и удобнее и производительнее.