c-smile wrote:

> Здравствуйте, eao197, Вы писали:
>
> E>А с этим я никогда и не спорил. Поэтому еще раз проясню свою позицию: я хочу увидеть реальные примеры (из реальных, а не тестовых примеров), когда использовались примитивы синхронизации, но приложение все равно работало не правильно до тех пор, пока не было использовано volatile. При этом меня не интересуют ни обработчики аппаратных прерываний, ни работа с железом через отображаемые в память порты ввода/вывода.
>
> E>Прошу не приводить примеров, когда компилятору специальными ключами явно указывали, что ни одна функция не имеет побочных эффектов. Применение такого ключа в многопоточной программе, ИМХО, является проявлением излишнего оптимизма программиста. Кроме того, такой пример я уже видел. Может есть что-то еще?

Во-первых, ты не привел кода, который мы просили привести: код, который использует ф-ции синхронизации для доступа к разделяемым переменным, но не работает когда эти разделяемые переменные не volatile.

> На моей задаче aliasing оптимизация дает 16% прирост производительности. Поэтому без этой оптимизации я даже и не компилирую.
> http://terrainformatica.com/htmlayout
>
> Вот фрагмент кода который без volatile просто не компилируется: например метод locked::dec(volatile long& cnt);

Вот тебе минимальный код, который вопреки твоим словам скомпилируется:

long l;
locked::dec(l);

> Использование критической секции вокруг mutex для проверки флагов active и terminate было протестировано и признано неоправданным — потеря производительности.
>
> Попытка использовать голые (не volatile) флаги вызывала очень странный behavior.

Почему не использовались InterlockedCompareExchangeRelease для чтения значений разделяемых переменных?

Если бы ты воспользовался этими ф-циями и заставил бы компилятор использовать intrinsic версии, твой код был бы не менее быстрым. InterlockedCompareExchangeRelease развернется на текущих Intel процессорах в LOCK CMPXCHG. Если destination в кэше процессора, то на современных процессорах Intel на шину не будет даже выставлен LOCK# сигнал.

Напротив же, ты воспользовался implementation defined семантикой volatile, сделав свой код гарантированно непереносимым на другие аппаратные платформы, поддерживаемые MS Windoze, компиляторы, а также следующие поколения процессоров Intel. Конечно, MS в лепешку разобъется, чтобы бинарники из кода такого качества работали на ее операционных системах и новейших процессорах Intel (при помощи MTRR), но в том режиме ты теряешь то, за что ты тут борешься — производительность.

На мой взгляд, этот очень типичный образчик multithreaded кода, написанного в заблуждениях относительно volatile: никакого прироста производительности от использования volatile вместо ф-ций синхронизации не достигнуто, лишь прибавилось потенциальных проблем.

> Вообще когда multithreading нечто начинает вести себя странно — ищи где ты забыл поставить volatile.

У меня есть чудесная мантра со 100% эффективностью от таких проблем:

Забудь про volatile, когда ты используешь multithreading.

--
Maxim Yegorushkin