Files
2025-10-25 03:02:53 +03:00

80 lines
3.4 KiB
Markdown
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

[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.5Freestanding 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.2Fundamental 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.2Operations 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.3Forward 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)