@standmit Ну мьютекс вовсе необязательно тормозит хоть что-нибудь, это зависит от имплементации и кода (например, вот обзор бустового мьютекса есть, он тут вообще не лочится: https://www.appsloveworld.com/cplus/100/33/why-is-stdmutex-faster-than-stdatomic ), а про барьеры — на восстановления когерентности кэшей между ядрами всё равно будет уходить время, причём тут зависит именно от процессора и от реализации этого самого протокола когерентности, а не от того, как расставлены барьеры в коде. Тут скорость зависит не только от кода и компилятора, но и от того, как код разлёгся по ядрам, что попало в кэши, и как оно себя ведёт. При аккуратно расставленных барьерах торможение будет, конечно, меньше, чем если везде лупить sequential consistent требование, но какое-то всё равно будет, и это стоит учитывать
@standmit ну и само собой, всё это относится скорее к очень суровому хайлоаду, когда мы начинаем экономить такты, и когда экономия сотни микросекунд, умноженная на миллиарды серверов очень конкретной аппаратной конфигурации, даёт миллионы долларов экономии.
В бытовом применении вряд ли углубление в такие детали имеет смысл. Скажем, сейчас почти любой бинарный дистрибутив линукса для x86_64 собирается под nehalem пятнадцатилетней давности, и всем норм. Какие уж тут войны за время синхронизации ядер :)