Как реализован std::atomic

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

Разница в том, что атомарные операции, которые не блокируются, не имеют «заблокированного» состояния. Давайте сравним два возможных способа атомарного приращения переменной:

Во-первых, мьютексный способ. Мы блокируем мьютекс, читаем-увеличиваем-записываем переменную, затем разблокируем мьютекс. Если поток будет прерван во время чтения-инкремента-записи, другие потоки, пытающиеся выполнить ту же операцию, будут заблокированы, пытаясь заблокировать мьютекс. (См. Где находится блокировка для std::atomic? для как это работает в некоторых реальных реализациях, для объектов слишком больших, чтобы быть lock_free.)

Во-вторых, атомный способ. ЦП «блокирует» только строку кэша, содержащую переменную, которую мы хотим изменить, на время выполнения одной инструкции чтения-увеличения-записи. (Это означает, что ЦП задерживает ответ на запросы MESI о признании недействительной или совместном использовании строки кэша, сохраняя эксклюзивный доступ, чтобы ни один другой ЦП не мог просмотреть ее. Когерентность кэша MESI всегда требует исключительного владения строкой кэша, прежде чем ядро ​​сможет изменить ее, поэтому это дешево, если мы уже владели линией). Мы не можем быть прерваны во время инструкции. Другой поток, пытающийся получить доступ к этой переменной, в худшем случае должен ждать, пока аппаратное обеспечение когерентности кеша определит, кто может изменять расположение памяти.

Так как же нам заблокировать мьютекс? Вероятно, мы выполняем атомарное сравнение и обмен. Таким образом, легкие атомарные операции — это примитивы, из которых собираются тяжелые операции мьютексов.

Конечно, это все зависит от платформы. Но это то, что делают типичные современные платформы, которые вы, вероятно, будете использовать.

в чем разница между std::atomic и мьютексом

Мьютекс — это конструкция параллелизма, независимая от каких-либо пользовательских данных, предлагающая lock и unlock методы, позволяющие защитить (взаимное исключение внутри) области кода. Вы можете поместить все, что хотите, в этот регион.

std::atomic<T> – это адаптер для одного экземпляра типа T, обеспечивающий атомарный доступ для каждой операции к этому объекту.

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

std::atomic существует в основном из-за другой распространенной реализации: использования атомарной инструкции² для непосредственного выполнения операции без использования мьютекса. Это реализация, используемая, когда std::atomic<T>::is_lock_free() возвращает true. Как правило, это более эффективно, чем подход с мьютексом, но применим только к объектам, достаточно маленьким, чтобы ими можно было манипулировать «одним выстрелом» с помощью атомарных инструкций.

² В некоторых случаях компилятор может использовать простые инструкции (а не специальные инструкции, связанные с параллелизмом), такие как нормальные загрузки и сохранения, если они обеспечивают требуемые гарантии на платформе. обсуждаемый.

Например, на x86 компиляторы реализуют все загрузки std::atomic для достаточно малых значений с простыми загрузками и реализовать все хранилища слабее, чем memory_order_seq_cst, с обычными хранилищами. Однако seq_cst хранилища реализованы со специальными инструкциями - завершающий mfence после mov в GCC до 10.1 и (неявный lock) xchg mem,reg в clang, недавнем GCC и других компиляторах.

Обратите также внимание на то, что асимметрия между загрузками и хранилищами является выбором компилятора: вместо этого они могли бы поместить специальную обработку в seq_cst загрузок, но поскольку загрузки обычно превосходят количество хранилищ, это в большинстве случаев медленнее. (И потому, что дешевые загрузки на быстрых путях более ценны.)