Files
cppdraft_translate/cppdraft/atomics/lockfree.md
2025-10-25 03:02:53 +03:00

80 lines
3.4 KiB
Markdown
Raw 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)