emusic wrote:

> Здравствуйте, MaximE, Вы писали:
>
> ME>Использование любого примитива синхронизации в POSIX и win32 является вызовом ф-ции. Вызов ф-ции — sequence point. Если у тебя уже есть sequence points вокруг защищаемых данных, зачем тогда volatile?
>
> Абсолютной необходимости в примитивах синхронизации нет. Если один процесс записывает значения в некоторую ячейку общей памяти, а другой их оттуда читает, и доступ к ячейке на всех поддерживаемых платформах гарантированно атомарный — какой смысл в дополнительных примитивах? Достаточно лишь указать компилятору, что с объектом нужно вести себя более аккуратно, что и делает volatile.

Атомарность и memory visibility ортогональны. См. мой предыдущий ответ.

[]

>>> Функции используются только для изменения volatile-переменных. Чтение их значений может происходить в параллельных потоках без каких-либо функций.
>
> ME>Это так только по случайному стечению обстоятельств на IA32.
>
> Почему по случайному? Еще не так давно подавляющее большинство платформ работало именно так.

Мы же работаем сегодня, а не вчера, верно?

> ME> volatile имеет влияние лишь на код, генерируемый компилятором. На переупорядочивание инструкций процессором он не имеет никакого влияния.
>
> А зачем? Назначение volatile — влиять именно на код. Соответственно, процессор своими средствами обеспечивает определенность вычислений.
>
> ME> Именно по этой причине на всех современных RISC процессорах, а также на IA64, тебе придется использовать барьеры памяти чтобы прочитать актуальное значение.
>
> Именно этим может и заниматься компилятор, обрабатывая volatile.

Ошибаешься. volatile не вставляет никаких барьеров. Барьеры обеспечиваются ф-циями http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/Synchro_88127404-a394-403f-a289-d61c45ab81d5.xml.asp

>>> ME> После sequence points, компилятор обязан перечитывать значения переменных из памяти, неважно, volatile ли, const ли, или это переменная без cv-квалификатора
>>>
>>> С чего бы он вдруг стал обязан? Компилятор обязан лишь обеспечить последовательное выполнение заданных действий в рамках одного потока исполнения. Для взаимодействия с "внешними" процессами и существует volatile.

volatile только для асинхронных обработчиков сигналов.

> ME>С тем, что состояние программы после sequence point is indeterminate.
>
> Из чего это следует?

Из стандарта С/С++.

[]

> А давай вместо вызова функции добавим модификацию объекта — например, введем переменную c и сделаем ей инкремент:
>
>

>   int c = b;
>
>   if (!a) {
>
>     c++;
>
>     b = a;
>
>   }
>
>   return c;
>

>
> Модификация объекта, согласно стандарту, есть sequence point. А по соглашениям MS любой оператор также является SP, и условие в if является ею же. Однако это не мешает компилятору по-прежнему использовать константу-нуль.

Вставь вызов ф-ции.

> ME>Мой point: volatile бесполезен (и даже вреден) для multithreading, барьеры нужны по-любому.
>
> Где в C++ барьеры?

В С++ их нет, в с++ нет multithreadind.

> Их там нет — они реализуются средствами платформы.

Это так.

> Наличие барьеров без volatile не гарантирует правильной работы. Наличие volatile без барьеров — тоже не гарантирует. volatile обеспечивает поддержку со стороны языка, барьер — со стороны аппаратуры.

Это ерунда. На POSIX все барьеры работают без volatile. POSIX работает практически на любой архитектуре. Почему это вдруг в vindoze на той же архитектуре понадобились volatile? Ответ один — от недопонимания.

> Зачем, по-твоему, вообще существует volatile? Именно для урезания вольностей оптимизатора в отношении состояния объекта.

volatile был введен в C и на сегодняшний день нужен только для асинхронных обработчиков сигналов. Точка.

--
Maxim Yegorushkin