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

Ф>Интересно, откуда инфа? Можно какие-нибудь доказательства [...] или дизасм получающегося кода, или объяснение того, что именно будет делать функция типа
Ф>

Ф>void Foo(){
Ф>Thread.MemoryBarrier();
Ф>}
Ф>

Ф>Я ОООчень бы хотел узнать, почему вы так думаете, откуда вы это взяли и где тут логика.
Ф>Т.е. если платформа не AMD64 будет действительно xchg. Но логики я тут всё равно не вижу.

Прежде всего, откуда я это взял. Работа такая

:-)

Да просто видел уже много-много раз при работе с крэш-дампами, в отладчике, в IDA Pro, при анализе ситуаций с зависаниями и другими проблемами.
Частенько приходится работать непосредственно с ассемблерными листингами, в основном это 32- и 64-битный код под архитектуры Intel/AMD (до ARM пока руки не дошли).
Также иногда интересно бывает написать что-то с использованием atomic или memory_order_xxx (C++) и посмотреть, во что компилятор превратит написанное.
И я вообще не припомню, чтобы хоть раз где-то видел sfence, lfence или mfence в многопоточке, в основном там всегда именно xchg, cmpxchg, xadd и т.п.

Эти инструкции, насколько я знаю, появились в SSE/SSE2 для поддержки non-temporal операций вроде movntdq, когда запись идет напрямую в память, не попадая в кэш CPU.
Т.е. они дают возможность упорядочивать такие операции более эффективным способом по сравнению с cpuid, например.

В обычном прикладном коде такие вещи практически не встречаются. Ну и сам по себе mfence, если верить дискуссиям в Гугле, занимает больше тактов CPU по сравнению с
locked-инструкциями типа xchg. Поэтому, а также ввиду определенных причин, связанных с особенностями работы Intel/AMD в этих аспектах, в "обычном" коде чаще
используется именно xchg, а не fence.

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

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

Ф>Интересно, откуда инфа? Можно какие-нибудь доказательства [...] или дизасм получающегося кода, или объяснение того, что именно будет делать функция типа
Ф>

Ф>void Foo(){
Ф>Thread.MemoryBarrier();
Ф>}
Ф>

Ф>Я ОООчень бы хотел узнать, почему вы так думаете, откуда вы это взяли и где тут логика.
Ф>Т.е. если платформа не AMD64 будет действительно xchg. Но логики я тут всё равно не вижу.

Прежде всего, откуда я это взял. Работа такая

:-)

Да просто видел уже много-много раз при работе с крэш-дампами, в отладчике, в IDA Pro, при анализе ситуаций с зависаниями и другими проблемами.
Частенько приходится работать непосредственно с ассемблерными листингами, в основном это 32- и 64-битный код под архитектуры Intel/AMD (до ARM пока руки не дошли).
Также иногда интересно бывает написать что-то с использованием atomic или memory_order_xxx (C++) и посмотреть, во что компилятор превратит написанное.
И я вообще не припомню, чтобы хоть раз где-то видел sfence, lfence или mfence в многопоточке, в основном там всегда именно xchg, cmpxchg, xadd и т.п.

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

В обычном прикладном коде такие вещи практически не встречаются. Ну и сам по себе mfence, если верить дискуссиям в Гугле, занимает больше тактов CPU по сравнению с
locked-инструкциями типа xchg. Поэтому, а также ввиду определенных причин, связанных с особенностями работы Intel/AMD в этих аспектах, в "обычном" коде чаще
используется именно xchg, а не fence.

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