bool atomic_compare_exchange_strong(volatile A *object, C *expected, C desired) bool atomic_compare_exchange_strong_explicit(volatile A *object, C *expected, C desired, memory_order success, memory_order failure) bool atomic_compare_exchange_strong_explicit(volatile A *object, C *expected, C desired, memory_order success, memory_order failure, memory_scope scope) bool atomic_compare_exchange_weak(volatile A *object, C *expected, C desired) bool atomic_compare_exchange_weak_explicit(volatile A *object, C *expected, C desired, memory_order success, memory_order failure) bool atomic_compare_exchange_weak_explicit(volatile A *object, C *expected, C desired, memory_order success, memory_order failure, memory_scope scope)
failureargument shall not be
These functions can only be used with an object of any atomic integer type.
failure argument shall be no stronger than the
Atomically, compares the value pointed to by
object for equality with that in
expected, and if true, replaces the value pointed to by
desired, and if false, updates the value in
expected with the value pointed to by
Further, if the comparison is true, memory is affected according to the value of
success, and if the comparison is false, memory is affected according to the value of
These operations are atomic read-modify-write operations (as defined by section 220.127.116.11 of the C11 specification).
|The effect of the compare-and-exchange operations is:|
if (memcmp(object, expected, sizeof(*object) == 0) memcpy(object, &desired, sizeof(*object)); else memcpy(expected, object, sizeof(*object));
The weak compare-and-exchange operations may fail spuriously.
That is, even when the contents of memory referred to by
object are equal, it may return zero and store back to
expected the same memory contents that were originally there.
This spurious failure enables implementation of compare-and-exchange on a broader class of machines, e.g.
load-locked store-conditional machines.
These generic functions return the result of the comparison.
In these operation definitions:
Arefers to one of the atomic types.
Crefers to its corresponding non-atomic type.
Mrefers to the type of the other argument for arithmetic operations. For atomic integer types,
The functions not ending in explicit have the same semantics as the corresponding explicit function with
The functions that do not have
memory_scopeargument have the same semantics as the corresponding functions with the
memory_scopeargument set to
|With fine-grained system SVM, sharing happens at the granularity of individual loads and stores anywhere in host memory. Memory consistency is always guaranteed at synchronization points, but to obtain finer control over consistency, the OpenCL atomics functions may be used to ensure that the updates to individual data values made by one unit of execution are visible to other execution units. In particular, when a host thread needs fine control over the consistency of memory that is shared with one or more OpenCL devices, it must use atomic and fence operations that are compatible with the C11 atomic operations.|
We can’t require C11 atomics since host programs can be implemented in other programming languages and versions of C or C++, but we do require that the host programs use atomics and that those atomics be compatible with those in C11.
All operations on atomic types must be performed using the built-in atomic functions. C11 and C++11 support operators on atomic types. OpenCL C does not support operators with atomic types. Using atomic types with operators should result in a compilation error.
atomic_uintmax_t types are not supported by OpenCL C.
OpenCL C requires that the built-in atomic functions on atomic types are lock-free.
_Atomic type specifier and
_Atomic type qualifier are not supported by OpenCL C.
The behavior of atomic operations where pointer arguments to the atomic functions refers to an atomic type in the private address space is undefined.