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

Y>Собственно вопрос.

Y>Если при доступе к переменной я окружаю код вызовами pthread_mutex_lock()/pthread_mutex_unlock(), то нужно ли при ее объявлении использовать квалификатор volatile?

В общем таки желательно.

Y>Где-то слышал, что компиляторы гарантируют, что после вызова функции в регистрах не окажется закэшированного значения переменной, но не уверен, так ли это.

Это так. Но вообще-то если Вы про "закэшированное", то связь с функциями lock/unlock тут иная. Не буду сильно вдаваться в подробности, но есть вопрос переупорядочения машинных команд по желанию процессора, и взятие лока должно быть гарантированно отработано до работы с данными, защищёнными этим локом, а освобождение лока — после такой работы. Думаю, Вам вспомнилось что-то из этой области.

Y> Да и даже если так, то что тогда произойдет, если pthread_mutex_lock() — inline-функция или макроопределение?

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

Y>Вообще, судя по http://alenacpp.blogspot.com/2006/04/volatile.html#comment-1976129473176086084 volatile все-таки стоит ставить.

Угумс.

Y> В таком случае встречный вопрос — а как быть с GTK в многопоточных приложениях? В отдельном потоке я могу создать виджеты с volatile, вызвать gdk_threads_enter()/gdk_threads_leave(), но GTK-то ничего знать о них не будет...

А в чём специфика ситуации? Расскажите. С GTK не работал.