Если учесть, что константные ф-ции нехорошо делать недетерминированными, то да, можешь.

а mutable? он является чем-то плохим, что лучше не пользовать?

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

Нет, с чего ты взял?

в смысле, если я вижу константную функцию, то я НАДЕЮСЬ, что она не меняет статическую mutable (по сути, глобальную переменную). А гарантий никаких.

В общем, вероятность подобного изврата край мала...

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

Вестимо, что так... Ну и, по аналогии, из такого метода не вызвать другие, менее cv-квалифицированные методы.
Я вот только не приложу ума, как это можно использовать в реальной жизни .

по аналогии с volatile для переменных
метод вполне может вызываться извне (для одного и того же объекта)
извне = другой поток или какое-либо асинхронное событие в основном потоке

MAKCim, итого - можно не ставить мутекс на чтение переменных, использующихся в методе. isn't it?

volatile переменные очень редкое явление и используются исключительно для работы с аппаратурой и для реализации самых примитивных примитивов синхронизации .

Добавлено через 3 минуты и 9 секунд

Либо мьютексы можно было бы не ставить и без volatile, либо, volatile не поможет при работе без мьютексов . Короче говоря, понятия несопоставимые .

archimed7592, ключевое слово в фразе было - "на чтение" 

JackYF, ещё раз:
либо читать можно без мьютекса - т.е. есть гарантии, что во время чтения не будет произведена запись. Такая гарантия есть, либо, когда происходит атомарная операция чтения(к примеру, чтение long long на x86 не является атомарной операцией), либо когда нет других потоков, работающих с переменной на запись.
либо, если нужен мьютекс, volatile не поможет.

Т.е. в данном случае:

метод и так может быть вызван(без его volatile-квалификации), а остальное зависит от логики работы этого метода(см. выше).

volatile даёт только одну гарантию: компилятор не может переставлять местами обращение к volatile переменным(даже чтение).
К примеру есть два порта, mapped to address space и представленные volatile переменными. Допустим тебе нужно отправить в первый порт какую-нибудь управляющую команду, а потом прочитать из второго порта результат. Компилятор гарантирует, что он не всунет чтение из второго порта перед записью в первый. Если ты уберёшь volatile-квалификацию, то с точки зрения компилятора, запись в одну переменную и чтение из другой - совершенно независимые операции и вполне сможет переставить их местами, ибо observable behaviour из-за этого не изменится.

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

  
без мьютексов и прочих вещей
это так, к слову
вообще я с тобой согласен

Это сообщение отредактировал(а) MAKCim - 11.11.2007, 10:37

ты же сам привел пример
вот реализация

Ну этот пример немного из пальца ;). Присутствуют только volatile-квалифицированные данные и они просто не могут быть не volatile.
К примеру, если у меня в классе есть поле, которое по идее меняться не должно, я из "стилевых" соображений сделаю это поле const вне зависимости от квалификации метода. По аналогии: здесь тоже я бы сразу поставил volatile на массив. Хотя... Какой-то смысл я в volatile-квалификации мьютекса начинаю видеть .