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

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

S>В том то и дело, что создают! Вспомните, как релизованы мембары на уровни ОС? Разве там есть, условно, membar(variable)? Нет, там есть просто membar(). Он не ассоциирован ни с какой переменной или объектом. Это просто барьер. И все synchronized, lock и volatile в конечном счете создают именно такие "просто" барьеры.
Спецификация volatile диктует минимальные требования. Реализация на барьерах только потому, что другого нет. К тому же барьер барьеру рознь, и что он значит сильно зависит от архитектуры. Потом в реализации volatile это не только ограничения на уровне CPU, это еще и ограничения на уровне компилятора, которые к барьерам отношения не имеют.

S>Поэтому я могу абсолютно легально сказать, что запись в волатильную переменную A happens-before чтения волатильной переменной B — вещи, происходящие на низком уровне (флаши и инвалидации кэшей, барьеры) абсолютно идентичны.
В конетной реализации и архтектуре такое сказать можно, но не более. К тому же чисто теоретически, утрируя, может быть такая ситуация, каждая операция в потоке выполняется на разном процессоре. В этом случае барьер может сработать совсем не там...

S>Проблема в другом — пытаясь сделать это на разных волатильных переменных мы никак не можем узнать делаем ли мы чтение из волатильной переменной B до или после записи в волатильную A. То есть барьеры, флаши, happens-before — все это происходит. Но не происходит передача состояния. А с одной переменной у нас есть и happens-before, и передача состояния, по которому мы потом можем сделать if.
Какое это имеет отношение к volatile? В вашем примере "передачи состояния" просто не может быть.