Уже несколько раз читал в разных местах, что volatile директива перед переменной не гарантирует атомарность операции с самой переменной, при работе с ней в несколько потоков. Так ли это ?
Действительно, разве изменение volatile bool или volatile BYTE переменной может быть не атомарной ? ведь это примитивный байтовый тип изменяемый за одну asm операцию. Или все же нужно менять содержимое таких переменных через Intelock???

Прошу помощи.

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

23W>Уже несколько раз читал в разных местах, что volatile директива перед переменной не гарантирует атомарность операции с самой переменной, при работе с ней в несколько потоков. Так ли это ?
23W>Действительно, разве изменение volatile bool или volatile BYTE переменной может быть не атомарной ? ведь это примитивный байтовый тип изменяемый за одну asm операцию. Или все же нужно менять содержимое таких переменных через Intelock???

23W>Прошу помощи.

volatile к атомарности не имеет вообще никакого отношения.

On 06.09.2011 13:46, 23W wrote:
> Уже несколько раз читал в разных местах, что volatile директива перед переменной
> не гарантирует атомарность операции с самой переменной, при работе с ней в
> несколько потоков. Так ли это ?

Так. volatile может быть объявлена любая переменная, любого типа.

Вообще, volatile -- это инструкция компилятору, чтобы он не делал
никаких предположений о текущем значении переменной для целей оптимизации.
Более ничего.

> Действительно, разве изменение volatile bool или volatile BYTE переменной может
> быть не атомарной ?

Может.

ведь это примитивный байтовый тип изменяемый за одну asm
> операцию.

Кто тебе это сказал ? Ссылку на стандарт даш ?

Или все же нужно менять содержимое таких переменных через Intelock???

Нужно. В смысле, нужно синхронизироваться, что такое Intelock я слабо представляю.

Для начала — компилятор имеет право вообще игнорировать модификатор.
А если не игнорирует, то должен отключать оптимизации при работе с этой переменной.
Что конкретно он должен делать и чего не должен — как я понимаю, не специфицировано.

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

BB>Здравствуйте, 23W, Вы писали:

23W>>Уже несколько раз читал в разных местах, что volatile директива перед переменной не гарантирует атомарность операции с самой переменной, при работе с ней в несколько потоков. Так ли это ?
23W>>Действительно, разве изменение volatile bool или volatile BYTE переменной может быть не атомарной ? ведь это примитивный байтовый тип изменяемый за одну asm операцию. Или все же нужно менять содержимое таких переменных через Intelock???

23W>>Прошу помощи.

BB>volatile к атомарности не имеет вообще никакого отношения.

т.е. изменение volatile bool переменной из нескольких цепочек ТРЕБУЕТ защиты ее через объекты синхронизации?

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

23W>т.е. изменение volatile bool переменной из нескольких цепочек ТРЕБУЕТ защиты ее через объекты синхронизации?

Да.

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

BB>Здравствуйте, 23W, Вы писали:
23W>>т.е. изменение volatile bool переменной из нескольких цепочек ТРЕБУЕТ защиты ее через объекты синхронизации?
BB>Да.

У меня тут есть определенный скепсис, как может изменение volatile bool или volatile BYTE быть не атомарным? Вы могли бы доказать или дать ссылку на стандарт или авторитет по этой теме.
Я понимаю что volatile отключает оптимизацию, т.е. гарантируется постоянная проверка переменной. Но ведь операция с байтом должна быть примитивной (атомарной).

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

23W>Уже несколько раз читал в разных местах, что volatile директива перед переменной не гарантирует атомарность операции с самой переменной, при работе с ней в несколько потоков. Так ли это ?
23W>Действительно, разве изменение volatile bool или volatile BYTE переменной может быть не атомарной ? ведь это примитивный байтовый тип изменяемый за одну asm операцию. Или все же нужно менять содержимое таких переменных через Intelock???

23W>Прошу помощи.

Почему она должна горантировать в С++ атомарность.
Не длжна просто оператор для того что бы эту переменную компелятор не поаптимизировал на случай если ты собираешься неведомымспособом для компилятора С++ модифицировать значение этой переменной.

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

23W>У меня тут есть определенный скепсис, как может изменение volatile bool или volatile BYTE быть не атомарным? Вы могли бы доказать или дать ссылку на стандарт или авторитет по этой теме.
23W>Я понимаю что volatile отключает оптимизацию, т.е. гарантируется постоянная проверка переменной. Но ведь операция с байтом должна быть примитивной (атомарной).

На интеловских процессорах load/store операции с данными, размером меньше разрядности (<= 4 для x86 и <= 8 для x64) атомарны.

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

23W>Здравствуйте, breee breee, Вы писали:

BB>>Здравствуйте, 23W, Вы писали:
23W>>>т.е. изменение volatile bool переменной из нескольких цепочек ТРЕБУЕТ защиты ее через объекты синхронизации?
BB>>Да.

23W>У меня тут есть определенный скепсис, как может изменение volatile bool или volatile BYTE быть не атомарным? Вы могли бы доказать или дать ссылку на стандарт или авторитет по этой теме.

изменение будет атомарным в пределах одного ядра. В случае нескольких ядер обязательно нужно использовать memory barrier, которые достигаются с помощью interlocked операций.

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

RB>На интеловских процессорах load/store операции с данными, размером меньше разрядности (<= 4 для x86 и <= 8 для x64) атомарны.

Только если они выравнены на границу 4(8) байт.

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

_>изменение будет атомарным в пределах одного ядра. В случае нескольких ядер обязательно нужно использовать memory barrier, которые достигаются с помощью interlocked операций.

В случае нескольких ядер отдельная load или store операция с данными размером в байт также будет атомарна.
Данные большего размера (2, 4, 8 на x64) байт обычно выровнены, поэтому операции с ними также будут атомарны.

Барьеры используются для обеспечения правильного порядка выполнения и видимости на других ядрах последовательных операций load/store.
Т.е., когда последовательно идут load-load, load-store, store-store или store-load операции.
Если у вас выполняется один load (или один store) из переменной volatile, где вы тут собираетесь барьеры вставлять?

Барьеры реализуются не только с помощью interlocked-операций, есть специальные команды процессора.
То, что interlocked-операция работает в качестве барьера, может зависеть от реализации процессора ("расслабленности").

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

23W>Здравствуйте, breee breee, Вы писали:

BB>>Здравствуйте, 23W, Вы писали:
23W>>>т.е. изменение volatile bool переменной из нескольких цепочек ТРЕБУЕТ защиты ее через объекты синхронизации?
BB>>Да.

23W>У меня тут есть определенный скепсис, как может изменение volatile bool или volatile BYTE быть не атомарным? Вы могли бы доказать или дать ссылку на стандарт или авторитет по этой теме.
Вам известны все существующие и будущие архитектуры процессоров, чтобы быть в этом увереным? Ссылку на стандарт дать невозможно, т.к. в текущем стандарте (2003 года) нет ничего про многопоточность, атомарность и т.д., поэтому мы должны предполагать худший случай.

23W>Я понимаю что volatile отключает оптимизацию, т.е. гарантируется постоянная проверка переменной.
Как сказали выше, есть еще проблема с видимостью изменения переменной между ядрами. Синхронизация обеспечивает эту видимость.

23W>Но ведь операция с байтом должна быть примитивной (атомарной).
Откуда эта информация?

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

BB>Здравствуйте, 23W, Вы писали:

23W>>Но ведь операция с байтом должна быть примитивной (атомарной).
BB>Откуда эта информация?
rus blood подтвердил (для x86 и x64 платформ).

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

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

_>>изменение будет атомарным в пределах одного ядра. В случае нескольких ядер обязательно нужно использовать memory barrier, которые достигаются с помощью interlocked операций.

RB>В случае нескольких ядер отдельная load или store операция с данными размером в байт также будет атомарна.
RB>Данные большего размера (2, 4, 8 на x64) байт обычно выровнены, поэтому операции с ними также будут атомарны.

RB>Барьеры используются для обеспечения правильного порядка выполнения и видимости на других ядрах последовательных операций load/store.
RB>Т.е., когда последовательно идут load-load, load-store, store-store или store-load операции.
RB>Если у вас выполняется один load (или один store) из переменной volatile, где вы тут собираетесь барьеры вставлять?

RB>Барьеры реализуются не только с помощью interlocked-операций, есть специальные команды процессора.
RB>То, что interlocked-операция работает в качестве барьера, может зависеть от реализации процессора ("расслабленности").

Т.е. я правильно понимаю что для данных размеров в байт (и это только тип char) можно не заморачиваться и считать что изменения volatile char будут атомарны. А вот при работе с двух-байтовыми данными (и более) нужна именно interlocked-операция, т.к. из-за невыровненности они могут быть неатомарны.

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

23W>>т.е. изменение volatile bool переменной из нескольких цепочек ТРЕБУЕТ защиты ее через объекты синхронизации?
BB>Да.

У VS есть нестандартное расширение трактовки volatile, это расширение гарантирует атомарность операции. В MSDN об этом написано.

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

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

23W>>>т.е. изменение volatile bool переменной из нескольких цепочек ТРЕБУЕТ защиты ее через объекты синхронизации?
BB>>Да.

S>У VS есть нестандартное расширение трактовки volatile, это расширение гарантирует атомарность операции. В MSDN об этом написано.
Вот это место из MSDN (http://msdn.microsoft.com/ru-ru/library/12a04hfd.aspx)

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

Also, when optimizing, the compiler must maintain ordering among references to volatile objects as well as references to other global objects. In particular, 

A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.

A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.

This allows volatile objects to be used for memory locks and releases in multithreaded applications.

и где тут про атомарность ?

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

S>У VS есть нестандартное расширение трактовки volatile, это расширение гарантирует атомарность операции. В MSDN об этом написано.

Об этом же пишет многоуважаемая АленаЦэКрестКрест.

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

23W>Здравствуйте, breee breee, Вы писали:

BB>>Здравствуйте, 23W, Вы писали:

23W>>>Но ведь операция с байтом должна быть примитивной (атомарной).
BB>>Откуда эта информация?
23W>rus blood подтвердил (для x86 и x64 платформ).

Это подфорум о чистом C++. Если конкретная платформа и компилятор обеспечивают атомарность, это еще не значит, что на это можно полагаться в общем случае.
Кроме того для x86 и x64, синхронизация все еще требуется для обеспечения видимости, насколько я понимаю.

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

23W>и где тут про атомарность ?

АленаCPP утверждает, что в доке к VS 2005 написано про атомарность volatile.