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

N>>компилятор может закэшировать a в регистре между её чтениями, или заменить второе присвоение на c=b, или сделать любое другое действие подобного типа. И без volatile ему никто это не запретит.
ДД>Для ядра пишут вот что: http://kernel.org/doc/Documentation/volatile-considered-harmful.txt.

Спасибо, отличный пример бреда сивой кобылы в лунную ночь. "Volatile плохо, потому что не позволяет разумную оптимизацию". То, что если оно позволит разумную — позволит и неразумную, тут не вспоминается, и никакие down(), mutex_lock() и прочие этому не помешают — если компилятор туп, то он однородно и равномерно туп. Именно это и происходит с GCC.

И в этой статье "забыли" упомянуть то, как оно реально в Linux лечится. А лечится — разделением на функции, между которыми оптимизация доступа к переменной уже не производится.

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

ДД> Уверен, что в userspace ситуация не сильно отличается. Если же все-таки существуют какие-нибудь более-менее официальные рекомендации по использованию volatile для защиты данных в мультинитевых приложениях, а не только домыслы анонимных комментаторов, буду благодарен за ссылки.

Я такого не видел, но я работаю только с GCC, для которого достаточно (AFAIR) вызова функции.