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

SK>Все варианты возможны. В данном сценарии нет никаких ограничений.
SK>>Если даже считывать ту же переменную, то все равно все будет так же, т.к. нет гарантии, что второй поток выполнится до присваивания volatile в первом.
SK>>Еще момент, что компилятор в праве переупорядочить присваивания 'a' и 'flag' или придумать еще более страшную оптимизацию, так как они не volatile.

S>В том то и дело, что есть ограничения. Семантика volatile такова, что его нельзя реордерить, и его чтение/запись выступают в роли "полупроницаемых" барьеров. Поэтому для кода:
S>

S>a = 1;
S>b = 1;
S>volatile = true;
S>

S>... возможны только два варианта выполнения:
S>

S>a = 1;
S>b = 1;
S>volatile = true;
S>

S>или
S>

S>b = 1;
S>a = 1;
S>volatile = true;
S>

S>Третьего не дано, запись в a и b гарантированно будет произведена до записи в volatile. Но для кода:
S>

S>a = 1;
S>b = 1;
S>volatile = true;
S>c = 1;
S>

S>... запись в с может быть произведена до записи в volatile (полупроницаемость).
S>Для volatile read все с точностью наоборот: код может пролезть "сверху", но не "снизу".

Я и не спорил так все и сказал. Разве нет? В последнем примере, присваивания 'a' и 'flag' можно менять местами,
Насчет ограничений, они не имеют знаничея для примера, т.к. никак на него не влияют. Из-за того, что в ващем примере нет условия с использованием volatile переменной, то абсолютно все равно были присваивания с ней переупорядочены или нет. Так, что логично сказать, что ограничений нет. Но это уже вопрос логики, а не volatile