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

O>Да просто видел уже много-много раз при работе с крэш-дампами, в отладчике, в IDA Pro, при анализе ситуаций с зависаниями и другими проблемами.

Видел что? Во что превращается c++ intrinsic _mm_mfence?

O>И я вообще не припомню, чтобы хоть раз где-то видел sfence, lfence или mfence в многопоточке, в основном там всегда именно xchg, cmpxchg, xadd и т.п.

Это потому, что указанные инструкции используются для атомарных операций, при этом суть их — блокировки. Все приведённые инструкции неявно выставляют LOCK# на шину. Барьеры же используются для lock-free алгоритмов.

O>sfence/lfence/mfence, насколько я знаю, появились в SSE/SSE2 для поддержки non-temporal операций вроде movntdq, когда запись идет напрямую в память, не попадая в кэш CPU.

О таков варианте использования в мануале по оптимизации для Pentium-4, где они впервые появились. К несчастью полную докуменацию по Pentium-4 мне не удалось найти — не могу ни подтвердить, ни опровергнуть

O>В обычном прикладном коде такие вещи практически не встречаются. Ну и сам по себе mfence, если верить дискуссиям в Гугле, занимает больше тактов CPU по сравнению с
O>locked-инструкциями типа xchg.

Весьма примерно представляю, как это проверить. Буду рад примеру кода, который подтвердит или опровергнет эту гипотезу.

O>Вообще, тема эта очень обширная и сложная, в двух-трех предложениях и малой части не описать.

Ооо! Это точно.


O>Например, очень часто компилятор не вставляет никаких специальных
O>барьеров туда, где ты вроде бы их ожидаешь. Например потому, что определенные гарантии предоставляет сама архитектура: "stores are not reordered with other stores" и т.д.

Не понимаю о чём идёт речь. Что и где должно теоретически быть, но не вставляет? Я думал, что синхронизация целиком и полностью ответственность программиста.