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

A>Прохождение барьера всегда связано с вызовом внешней функции. Объект, к которому возможно обращение из нескольких потоков — либо глобальный, либо к нему ранее были созданы пути доступа, которые компилятор отследить не в силах. Следовательно, компилятор обязан предполагать возможность изменения данных объектов.

Я дважды приводил два примера. Один — со статическим переменными/функциями, обращения к которым компилятор легко может отследить и установить, что, извне ни одна переменная не изменяется. Что в данном случае может удержать компилятор от оптимизации работы с этими переменными, и заставить его предполагать, что после вызова какой-то там внешней функции локальные для модуля статические переменные вдруг изменятся?

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

A>Разумеется, это не касается случая, когда включена форсированная оптимизация. Ну, это уже ваш собственный выбор — у компилятора к услугам обманщиков вообще есть широчайший ассортимент способов устроить неопределенное поведение.

Прошу показать мне место в описании ключей /Ow и /Oa компилятора MS VC++, где об этом говорится.

A>По мне так это несильно отличается от вот такого:

A>

A>int f()
A>{
A>    char const* const p = "aaa";
A>    *const_cast<char*>(p) = 'b';
A>    const_cast<char const*&>(p) = p + 1;
A>}
A>

Отличается принципиально. В силу того, что единственная языковая конструкция, применимая к multithreading — этот самый volatile. И почему-то компилятор, "обманутый" в моем примере ключом /Oa, при добавлении volatile к определению переменных вдруг начинает генерировать совершенно работоспособный код. Наверное, это случайность, да? А какие уточняющие спецификаторы нужно внести в вышеприведенный код, чтобы обманутый (уже без кавычек) компилятор сделал все правильно?

A>Если же барьер не обеспечивает синхронизации памяти между процессорами, — ну тут уж извиняйте — никакое volatile вам не поможит.

Разумеется. О чем я и говорил — что без volatile многопоточный код будет в общем случае некорректен, и все доводы противников volatile о том, что у них все работает опираются исключительно на совокупность частных случаев.

A>В Си/Си++ как языке просто нет легальных средств для такой тонкой оптимизации.

Не понял. Какие, по-Вашему, в Си/Си++ вообще есть "легальные средства для оптимизации"? Я не знаю ни одного В языке есть средства, которые могут помочь проводить оптимизацию, но и только. И которые с развитием техники оптимизации в компиляторах постепенно утрачивают значение — register давно стал бесполезен, арифметические операции ++/-- тоже давно перестали быть эффективнее прибавления/вычитания единицы.

Собственно, меня вообще удивляет, почему следующее утверждение кто-то не согласен считать аксиомой: "До тех пор, пока в языке C++ не появится средств для указания наличия многопоточности, компилятор имеет право на любую оптимизацию, при которой сохраняется правильное поведение программы в однопоточном варианте". Аргументированных возражений никто до сих пор не привел. Единственное, что в C/C++ хотя бы косвенно указывает на какую-то асинхронность — это volatile.