[atomics.lockfree]

# 32 Concurrency support library [[thread]](./#thread)

## 32.5 Atomic operations [[atomics]](atomics#lockfree)

### 32.5.5 Lock-free property [atomics.lockfree]

[🔗](#:values_of_various_ATOMIC_..._LOCK_FREE_macros)

#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*

[1](#1)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L3101)

The ATOMIC_..._LOCK_FREE macros indicate the lock-free property of the
corresponding atomic types, with the signed and unsigned variants grouped
together[.](#1.sentence-1)

The properties also apply to the corresponding (partial) specializations of theatomic template[.](#1.sentence-2)

A value of 0 indicates that the types are never
lock-free[.](#1.sentence-3)

A value of 1 indicates that the types are sometimes lock-free[.](#1.sentence-4)

A
value of 2 indicates that the types are always lock-free[.](#1.sentence-5)

[2](#2)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L3109)

On a hosted implementation ([[compliance]](compliance "16.4.2.5 Freestanding implementations")),
at least one signed integral specialization of the atomic template,
along with the specialization
for the corresponding unsigned type ([[basic.fundamental]](basic.fundamental "6.9.2 Fundamental types")),
is always lock-free[.](#2.sentence-1)

[3](#3)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L3116)

The functions atomic<T>​::​is_lock_free andatomic_is_lock_free ([[atomics.types.operations]](atomics.types.operations "32.5.8.2 Operations on atomic types"))
indicate whether the object is lock-free[.](#3.sentence-1)

In any given program execution, the
result of the lock-free query
is the same for all atomic objects of the same type[.](#3.sentence-2)

[4](#4)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L3123)

Atomic operations that are not lock-free are considered to potentially
block ([[intro.progress]](intro.progress "6.10.2.3 Forward progress"))[.](#4.sentence-1)

[5](#5)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L3127)

*Recommended practice*: Operations that are lock-free should also be address-free[.](#5.sentence-1)[294](#footnote-294 "That is, atomic operations on the same memory location via two different addresses will communicate atomically.")

The implementation of these operations should not depend on any per-process state[.](#5.sentence-2)

[*Note [1](#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[.](#5.sentence-3)

— *end note*]

[294)](#footnote-294)[294)](#footnoteref-294)

That is,
atomic operations on the same memory location via two different addresses will
communicate atomically[.](#footnote-294.sentence-1)