Почему std :: atomic <T> :: is_lock_free () не является статичным, как constexpr?

Может кто-нибудь сказать мне, является ли std :: atomic :: is_lock_free () не статичным, а также constexpr? Не иметь смысла в том, чтобы он был нестатичным и / или неконстекстовым.

Как объяснено на cppreference :

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

Стандарт C ++ рекомендует (но не требует), чтобы атомарные операции без блокировки также были безадресными, то есть подходящими для связи между процессами, использующими разделяемую память.

Как уже упоминалось несколькими другими, std::is_always_lock_freeможет быть то, что вы действительно ищете.

Редактировать: Чтобы уточнить, типы объектов C ++ имеют значение выравнивания, которое ограничивает адреса их экземпляров только определенными кратными степенями two ( [basic.align]). Эти значения выравнивания определяются реализацией для основных типов и не должны равняться размеру типа. Они также могут быть более строгими, чем то, что на самом деле может поддерживать оборудование.

Например, x86 (в основном) поддерживает невыровненный доступ. Тем не менее, вы найдете большинство компиляторов alignof(double) == sizeof(double) == 8для x86, поскольку невыровненный доступ имеет множество недостатков (скорость, кэширование, атомарность ...). Но, например, #pragma pack(1) struct X { char a; double b; };или alignas(1) double x;позволяет вам иметь «не выровненные» doubleс. Поэтому, когда cppreference говорит о «выровненных обращениях к памяти», он, по-видимому, делает это с точки зрения естественного выравнивания типа для аппаратного обеспечения, не используя тип C ++ таким образом, который противоречит его требованиям к выравниванию (которое будет UB).

Вот дополнительная информация: Каков реальный эффект от успешного доступа без выравнивания на x86?

Пожалуйста, ознакомьтесь с проницательными комментариями @Peter Cordes ниже!

Вы можете использовать std::is_always_lock_free

is_lock_free зависит от конкретной системы и не может быть определена во время компиляции.

Соответствующее объяснение:

Атомарные типы также могут иногда быть свободными от блокировки, например, если только выровненные обращения к памяти естественным образом атомарны в данной архитектуре, неправильно выровненные объекты одного типа должны использовать блокировки.

Я установил Visual Studio 2019 на свой Windows-ПК, и у этого устройства также есть ARMv8-компилятор. ARMv8 допускает не выровненный доступ, но сравнение и обмен, заблокированные добавления и т. Д. Должны быть выровнены. Кроме того, чистая загрузка / чистое хранение с использованием ldpили stp(пара загрузки или пара хранения 32-разрядных регистров) гарантированно будут атомарными, только если они естественным образом выровнены.

Поэтому я написал небольшую программу для проверки того, что is_lock_free () возвращает для произвольного атомного указателя. Итак, вот код:

#include <atomic>
#include <cstddef>

using namespace std;

bool isLockFreeAtomic( atomic<uint64_t> *a64 )
{
    return a64->is_lock_free();
}

И это разборка isLockFreeAtomic

|?isLockFreeAtomic@@YA_NPAU?$atomic@_K@std@@@Z| PROC
    movs        r0,#1
    bx          lr
ENDP

Это просто returns true, ака 1.

Эта реализация выбирает для использования, alignof( atomic<int64_t> ) == 8так что каждый atomic<int64_t>правильно выровнен. Это исключает необходимость проверки выравнивания во время выполнения при каждой загрузке и хранении.

(Примечание редактора: это часто встречается; большинство реальных реализаций C ++ работают именно так. Вот почему std::is_always_lock_freeэто так полезно: потому что это обычно верно для типов, где is_lock_free()всегда верно.)