[atomics.lockfree] (original) (raw)

32 Concurrency support library [thread]

32.5 Atomic operations [atomics]

32.5.5 Lock-free property [atomics.lockfree]

#define ATOMIC_BOOL_LOCK_FREE unspecified #define ATOMIC_CHAR_LOCK_FREE unspecified #define ATOMIC_CHAR8_T_LOCK_FREE unspecified #define ATOMIC_CHAR16_T_LOCK_FREE unspecified #define ATOMIC_CHAR32_T_LOCK_FREE unspecified #define ATOMIC_WCHAR_T_LOCK_FREE unspecified #define ATOMIC_SHORT_LOCK_FREE unspecified #define ATOMIC_INT_LOCK_FREE unspecified #define ATOMIC_LONG_LOCK_FREE unspecified #define ATOMIC_LLONG_LOCK_FREE unspecified #define ATOMIC_POINTER_LOCK_FREE unspecified

The ATOMIC_..._LOCK_FREE macros indicate the lock-free property of the corresponding atomic types, with the signed and unsigned variants grouped together.

The properties also apply to the corresponding (partial) specializations of theatomic template.

A value of 0 indicates that the types are never lock-free.

A value of 1 indicates that the types are sometimes lock-free.

A value of 2 indicates that the types are always lock-free.

On a hosted implementation ([compliance]), at least one signed integral specialization of the atomic template, along with the specialization for the corresponding unsigned type ([basic.fundamental]), is always lock-free.

The functions atomic<T>​::​is_lock_free andatomic_is_lock_free ([atomics.types.operations]) indicate whether the object is lock-free.

In any given program execution, the result of the lock-free query is the same for all atomic objects of the same type.

Atomic operations that are not lock-free are considered to potentially block ([intro.progress]).

Recommended practice: Operations that are lock-free should also be address-free.294

The implementation of these operations should not depend on any per-process state.

[Note 1:

This restriction enables communication by memory that is mapped into a process more than once and by memory that is shared between two processes.

— _end note_]