¿Por qué std :: atomic <T> :: is_lock_free () no es estático ni constexpr?

¿Alguien puede decirme si std :: atomic :: is_lock_free () no es estático y constexpr? Tenerlo no estático y / o como no constexpr no tiene sentido para mí.

Como se explica en cppreference :

Todos los tipos atómicos, excepto std :: atomic_flag, pueden implementarse utilizando mutexes u otras operaciones de bloqueo, en lugar de utilizar las instrucciones de la CPU atómica sin bloqueo. A veces, los tipos atómicos también pueden estar libres de bloqueo, por ejemplo, si solo los accesos de memoria alineados son naturalmente atómicos en una arquitectura dada, los objetos desalineados del mismo tipo tienen que usar bloqueos.

El estándar C ++ recomienda (pero no requiere) que las operaciones atómicas sin bloqueo también estén libres de dirección, es decir, adecuadas para la comunicación entre procesos que utilizan memoria compartida.

Como lo mencionaron muchos otros, std::is_always_lock_freepodría ser lo que realmente estás buscando.

Editar: para aclarar, los tipos de objetos C ++ tienen un valor de alineación que restringe las direcciones de sus instancias a solo ciertos múltiplos de potencias de dos ( [basic.align]). Estos valores de alineación están definidos por la implementación para los tipos fundamentales y no necesitan ser iguales al tamaño del tipo. También pueden ser más estrictos de lo que el hardware podría soportar.

Por ejemplo, x86 (principalmente) admite accesos no alineados. Sin embargo, encontrará que la mayoría de los compiladores tienen alignof(double) == sizeof(double) == 8para x86, ya que los accesos no alineados tienen una serie de desventajas (velocidad, almacenamiento en caché, atomicidad ...). Pero, por ejemplo, #pragma pack(1) struct X { char a; double b; };o le alignas(1) double x;permite tener "no alineados" double. Entonces, cuando cppreference habla de "accesos de memoria alineados", presumiblemente lo hace en términos de la alineación natural del tipo para el hardware, no utilizando un tipo C ++ de una manera que contradiga sus requisitos de alineación (que sería UB).

Aquí hay más información: ¿Cuál es el efecto real de los accesos no alineados exitosos en x86?

¡Por favor también mire los comentarios perspicaces de @Peter Cordes a continuación!

Puedes utilizar std::is_always_lock_free

is_lock_free depende del sistema real y no se puede determinar en tiempo de compilación.

Explicación relevante:

Los tipos atómicos también pueden estar libres de bloqueo, por ejemplo, si solo los accesos de memoria alineados son naturalmente atómicos en una arquitectura dada, los objetos desalineados del mismo tipo tienen que usar bloqueos.

Instalé Visual Studio 2019 en mi PC con Windows y este dispositivo también tiene un compilador ARMv8. ARMv8 permite accesos no alineados, pero la comparación y los intercambios, las adiciones bloqueadas, etc. están obligados a alinearse. Y también la carga pura / almacenamiento puro usando ldpo stp(pares de carga o pares de almacenamiento de registros de 32 bits) solo se garantiza que sean atómicos cuando están naturalmente alineados.

Entonces escribí un pequeño programa para verificar qué devuelve is_lock_free () para un puntero atómico arbitrario. Así que aquí está el código:

#include <atomic>
#include <cstddef>

using namespace std;

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

Y este es el desmontaje de isLockFreeAtomic

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

Esto es solo returns true, alias 1.

Esta implementación elige usar alignof( atomic<int64_t> ) == 8para que todos atomic<int64_t>estén correctamente alineados. Esto evita la necesidad de verificaciones de alineación de tiempo de ejecución en cada carga y almacén.

(Nota del editor: esto es común; la mayoría de las implementaciones de C ++ en la vida real funcionan de esta manera. Por eso std::is_always_lock_freees tan útil: porque generalmente es cierto para tipos donde is_lock_free()siempre es cierto).