Гарантирует ли std::atomic<T> отсутствие внутренних блокировок для любого типа T?
Нет. std::atomic<T> гарантирует атомарность операций и соблюдение модели памяти, но не гарантирует их lock-free-реализацию. Для некоторых типов библиотека может использовать внутренний механизм блокировки.
Проверить это можно через is_lock_free() во время выполнения или is_always_lock_free во время компиляции. Даже lock-free не означает, что операция гарантированно завершится за ограниченное число шагов: это более слабая гарантия, чем wait-free.
До стандартизации многопоточности в C++ разработчики зависели от нестандартных расширений процессора и библиотек синхронизации. C++11 ввёл std::atomic, чтобы единообразно описать атомарные операции, порядок памяти и взаимодействие потоков.
Аппаратная поддержка атомарности различается для типов и платформ. Поэтому стандарт отделяет требование корректности от требования производительности: атомик обязан работать атомарно, но конкретная реализация не обязана обходиться без внутренних блокировок.
Разработчик может выбрать std::atomic<T>, предполагая, что это всегда более быстрый и неблокирующий вариант обычного мьютекса. Для небольших целочисленных типов это часто соответствует возможностям процессора, но для крупных или нестандартно выровненных типов реализация может использовать скрытую блокировку.
Это особенно важно в коде с жёсткими требованиями к задержкам, в обработчиках сигналов, низкоуровневых компонентах и алгоритмах, где блокировка может привести к взаимному влиянию потоков. Ошибочное предположение о lock-free-свойствах способно нарушить требования к времени отклика, хотя формально гонки данных не возникнет.
std::atomic<T> задаёт атомарность доступа к объекту и позволяет применять порядки памяти, например relaxed, acquire и release. Эти гарантии сохраняются независимо от того, реализованы операции напрямую инструкциями процессора или через внутренний механизм библиотеки.
Метод is_lock_free() сообщает, является ли конкретный объект lock-free на данной платформе и в конкретных условиях реализации. Свойство is_always_lock_free показывает, гарантируется ли lock-free-реализация для данного типа на всех поддерживаемых конфигурациях этой реализации.
Проверка is_lock_free() не делает операцию lock-free, а только сообщает её свойство. Если lock-free необходим как обязательное требование, это нужно явно проверять на целевых платформах и учитывать размер, выравнивание и тип атомика.
Lock-free означает, что система в целом продолжает продвигаться: при конкуренции хотя бы одна операция завершается за конечное число шагов. Это не гарантирует отсутствие голодания конкретного потока. Wait-free дополнительно ограничивает число шагов для каждой отдельной операции и потому является более сильным свойством.
В высокочастотном компоненте используется атомарный 128-битный счётчик. На одной архитектуре операции выполняются аппаратно, а на другой библиотека применяет внутреннюю блокировку. Среднее время работы остаётся приемлемым, но под нагрузкой появляются неожиданные задержки.
Вариант с обычным std::atomic прост и корректен, однако не обеспечивает требуемые свойства задержки. Вариант с мьютексом делает блокирующее поведение явным, но обычно добавляет те же или большие накладные расходы. Вариант с платформенным lock-free-примитивом даёт предсказуемое поведение, но ухудшает переносимость и усложняет сопровождение.
Обоснованное решение — сначала проверить is_always_lock_free и is_lock_free() на всех целевых конфигурациях. Если lock-free является обязательным требованием, следует выбрать поддерживаемый размер атомика либо изолировать платформенную реализацию за небольшим интерфейсом; если важна только корректность, обычный std::atomic предпочтительнее по переносимости.
Не обязательно в смысле конкретной реализации каждой вспомогательной операции программы, но для атомарной операции это свойство означает отсутствие блокирующего механизма, из-за которого прогресс мог бы остановиться при вытеснении удерживающего потокa. Проверять нужно именно свойство используемого атомарного объекта или типа, а не делать вывод по его названию.
is_lock_free() для доказательства отсутствия задержек?Нет. Lock-free гарантирует прогресс системы, но не ограничивает время ожидания конкретного потока и не запрещает повторные конфликты, вытеснения или задержки памяти. Для жёсткой верхней границы времени требуется wait-free-алгоритм либо отдельное доказательство временных свойств всей системы.
Порядок памяти меняет правила видимости и упорядочивания, но не превращает атомарный тип автоматически в lock-free или обратно. Однако конкретная реализация может выбирать разные инструкции и пути выполнения для разных операций, поэтому окончательные свойства следует проверять на нужной платформе, а не выводить только из выбранного memory_order.