tmp/tmph_v3wmr1/{from.md → to.md}
RENAMED
|
@@ -1,10 +1,11 @@
|
|
| 1 |
## Lock-free property <a id="atomics.lockfree">[[atomics.lockfree]]</a>
|
| 2 |
|
| 3 |
``` cpp
|
| 4 |
#define ATOMIC_BOOL_LOCK_FREE unspecified
|
| 5 |
#define ATOMIC_CHAR_LOCK_FREE unspecified
|
|
|
|
| 6 |
#define ATOMIC_CHAR16_T_LOCK_FREE unspecified
|
| 7 |
#define ATOMIC_CHAR32_T_LOCK_FREE unspecified
|
| 8 |
#define ATOMIC_WCHAR_T_LOCK_FREE unspecified
|
| 9 |
#define ATOMIC_SHORT_LOCK_FREE unspecified
|
| 10 |
#define ATOMIC_INT_LOCK_FREE unspecified
|
|
@@ -19,19 +20,26 @@ grouped together. The properties also apply to the corresponding
|
|
| 19 |
(partial) specializations of the `atomic` template. A value of 0
|
| 20 |
indicates that the types are never lock-free. A value of 1 indicates
|
| 21 |
that the types are sometimes lock-free. A value of 2 indicates that the
|
| 22 |
types are always lock-free.
|
| 23 |
|
| 24 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 25 |
indicates whether the object is lock-free. In any given program
|
| 26 |
execution, the result of the lock-free query shall be consistent for all
|
| 27 |
pointers of the same type.
|
| 28 |
|
| 29 |
Atomic operations that are not lock-free are considered to potentially
|
| 30 |
-
block
|
| 31 |
|
| 32 |
-
[*Note
|
| 33 |
That is, atomic operations on the same memory location via two different
|
| 34 |
addresses will communicate atomically. The implementation should not
|
| 35 |
depend on any per-process state. This restriction enables communication
|
| 36 |
by memory that is mapped into a process more than once and by memory
|
| 37 |
that is shared between two processes. — *end note*]
|
|
|
|
| 1 |
## Lock-free property <a id="atomics.lockfree">[[atomics.lockfree]]</a>
|
| 2 |
|
| 3 |
``` cpp
|
| 4 |
#define ATOMIC_BOOL_LOCK_FREE unspecified
|
| 5 |
#define ATOMIC_CHAR_LOCK_FREE unspecified
|
| 6 |
+
#define ATOMIC_CHAR8_T_LOCK_FREE unspecified
|
| 7 |
#define ATOMIC_CHAR16_T_LOCK_FREE unspecified
|
| 8 |
#define ATOMIC_CHAR32_T_LOCK_FREE unspecified
|
| 9 |
#define ATOMIC_WCHAR_T_LOCK_FREE unspecified
|
| 10 |
#define ATOMIC_SHORT_LOCK_FREE unspecified
|
| 11 |
#define ATOMIC_INT_LOCK_FREE unspecified
|
|
|
|
| 20 |
(partial) specializations of the `atomic` template. A value of 0
|
| 21 |
indicates that the types are never lock-free. A value of 1 indicates
|
| 22 |
that the types are sometimes lock-free. A value of 2 indicates that the
|
| 23 |
types are always lock-free.
|
| 24 |
|
| 25 |
+
At least one signed integral specialization of the `atomic` template,
|
| 26 |
+
along with the specialization for the corresponding unsigned type
|
| 27 |
+
[[basic.fundamental]], is always lock-free.
|
| 28 |
+
|
| 29 |
+
[*Note 1*: This requirement is optional in freestanding implementations
|
| 30 |
+
[[compliance]]. — *end note*]
|
| 31 |
+
|
| 32 |
+
The function `atomic_is_lock_free` [[atomics.types.operations]]
|
| 33 |
indicates whether the object is lock-free. In any given program
|
| 34 |
execution, the result of the lock-free query shall be consistent for all
|
| 35 |
pointers of the same type.
|
| 36 |
|
| 37 |
Atomic operations that are not lock-free are considered to potentially
|
| 38 |
+
block [[intro.progress]].
|
| 39 |
|
| 40 |
+
[*Note 2*: Operations that are lock-free should also be address-free.
|
| 41 |
That is, atomic operations on the same memory location via two different
|
| 42 |
addresses will communicate atomically. The implementation should not
|
| 43 |
depend on any per-process state. This restriction enables communication
|
| 44 |
by memory that is mapped into a process more than once and by memory
|
| 45 |
that is shared between two processes. — *end note*]
|