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

>>

>> int volatile nVint;
>>
>> Objects declared as volatile are not used in optimizations because their value can change at any time. The system always reads the current value of a volatile object at the point it is requested, even if the previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.

ME>Андрей, я подразумеваю, что русский мы понимаем на равных, и английский мы знаем достаточно, хотя бы для того, чтобы после фразы "would you like to go out with me tonight?" на следущее утро также накормить девушку завтраком?

ME>Так вот, где в приведенной тобой цитате сказано
ME>

ME>... пока мне четко не скажут в док-ции к компилятору/api, что это необходимо

OK. Let's rephrase this as: If you want to assure the value of variable to appear at its memory location upon assignment you must
declare this variable as a volatile. According to VC++ documentation this is the only legal way to exclude assignment to it from any optimizations.

Это если следовать формальной логике.

Ты пойми, никакого формального же описания "барьеров" в документации VC++ просто нет. Собственно как и ни в каком другом компиляторе.
Единственное что есть это volatile.

"Барьер" это некая абстракция верхнего уровня которая имплементируется везде где я только это видел на volatile переменных.

Вот например свежий патч к GCC по поводу создания барьеров:

My patch for PR c++/13684 implemented thread-safe initialization of C++
static local variables, using the double-checked locking pattern:

http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01888.html