Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

atomic_ops(3) [netbsd man page]

ATOMIC_OPS(3)						   BSD Library Functions Manual 					     ATOMIC_OPS(3)

NAME
atomic_ops -- atomic memory operations SYNOPSIS
#include <sys/atomic.h> DESCRIPTION
The atomic_ops family of functions provide atomic memory operations. There are 7 classes of atomic memory operations available: atomic_add(3) These functions perform atomic addition. atomic_and(3) These functions perform atomic logical ``and''. atomic_cas(3) These functions perform atomic compare-and-swap. atomic_dec(3) These functions perform atomic decrement. atomic_inc(3) These functions perform atomic increment. atomic_or(3) These functions perform atomic logical ``or''. atomic_swap(3) These functions perform atomic swap. Synchronization Mechanisms Where the architecture does not provide hardware support for atomic compare and swap (CAS), atomicity is provided by a restartable sequence or by a spinlock. The chosen method is not ordinarily distinguishable by or visible to users of the interface. The following architectures can be assumed to provide CAS in hardware: alpha, amd64, i386, powerpc, powerpc64, sparc64. Scope and Restrictions If hardware CAS is available, the atomic operations are globally atomic: operations within a memory region shared between processes are guar- anteed to be performed atomically. If hardware CAS is not available, it may only be assumed that the operations are atomic with respect to threads in the same process. Additionally, if hardware CAS is not available, the atomic operations must not be used within a signal handler. Users of atomic memory operations should not make assumptions about how the memory access is performed (specifically, the width of the memory access). For this reason, applications making use of atomic memory operations should limit their use to regular memory. The results of using atomic memory operations on anything other than regular memory are undefined. Users of atomic memory operations should take care to modify any given memory location either entirely with atomic operations or entirely with some other synchronization mechanism. Intermixing of atomic operations with other synchronization mechanisms for the same memory loca- tion results in undefined behavior. Visibility and Ordering of Memory Accesses If hardware CAS is available, stores to the target memory location by an atomic operation will reach global visibility before the operation completes. If hardware CAS is not available, the store may not reach global visibility until some time after the atomic operation has com- pleted. However, in all cases a subsequent atomic operation on the same memory cell will be delayed until the result of any preceeding oper- ation has reached global visibility. Atomic operations are strongly ordered with respect to each other. The global visibility of other loads and stores before and after an atomic operation is undefined. Applications that require synchronization of loads and stores with respect to an atomic operation must use memory barriers. See membar_ops(3). Performance Because atomic memory operations require expensive synchronization at the hardware level, applications should take care to minimize their use. In certain cases, it may be more appropriate to use a mutex, especially if more than one memory location will be modified. SEE ALSO
atomic_add(3), atomic_and(3), atomic_cas(3), atomic_dec(3), atomic_inc(3), atomic_or(3), atomic_swap(3), membar_ops(3) HISTORY
The atomic_ops functions first appeared in NetBSD 5.0. BSD
April 14, 2010 BSD

Check Out this Related Man Page

ATOMIC_CAS(3)						   BSD Library Functions Manual 					     ATOMIC_CAS(3)

NAME
atomic_cas, atomic_cas_32, atomic_cas_uint, atomic_cas_ulong, atomic_cas_ptr, atomic_cas_64, atomic_cas_32_ni, atomic_cas_uint_ni, atomic_cas_ulong_ni, atomic_cas_ptr_ni, atomic_cas_64_ni -- atomic compare-and-swap operations SYNOPSIS
#include <sys/atomic.h> uint32_t atomic_cas_32(volatile uint32_t *ptr, uint32_t old, uint32_t new); unsigned int atomic_cas_uint(volatile unsigned int *ptr, unsigned int old, unsigned int new); unsigned long atomic_cas_ulong(volatile unsigned long *ptr, unsigned long old, unsigned long new); void * atomic_cas_ptr(volatile void *ptr, void *old, void *new); uint64_t atomic_cas_64(volatile uint64_t *ptr, uint64_t old, uint64_t new); uint32_t atomic_cas_32_ni(volatile uint32_t *ptr, uint32_t old, uint32_t new); unsigned int atomic_cas_uint_ni(volatile unsigned int *ptr, unsigned int old, unsigned int new); unsigned long atomic_cas_ulong_ni(volatile unsigned long *ptr, unsigned long old, unsigned long new); void * atomic_cas_ptr_ni(volatile void *ptr, void *old, void *new); uint64_t atomic_cas_64_ni(volatile uint64_t *ptr, uint64_t old, uint64_t new); DESCRIPTION
The atomic_cas family of functions perform a compare-and-swap operation in an atomic fashion. The value of the variable referenced by ptr is compared against old. If the values are equal, new is stored in the variable referenced by ptr. The old value of the variable referenced by ptr is always returned regardless of whether or not the new value was stored. Applications can test for success of the operation by comparing the return value to the value passed as old; if they are equal then the new value was stored. The non-interlocked variants, *_ni(), guarantee atomicity within the same CPU with respect to interrupts and preemption. For example, they are suitable for synchronizing compare-and-swap operations on a variable shared by a thread and an interrupt that are bound to the same CPU. The *_ni() variants are not atomic with respect to different CPUs. *_ni() variants should avoid the interprocessor synchronization overhead of the standard compare-and-swap operations. The 64-bit variants of these functions are available only on platforms that can support atomic 64-bit memory access. Applications can check for the availability of 64-bit atomic memory operations by testing if the pre-processor macro __HAVE_ATOMIC64_OPS is defined. SEE ALSO
atomic_ops(3) HISTORY
The atomic_cas functions first appeared in NetBSD 5.0. NOTES
On some architectures, a *_ni() variant is merely an alias for the corresponding standard compare-and-swap operation. While the non-inter- locked variant behaves correctly on those architectures, it does not avoid the interprocessor synchronization overhead. BSD
February 11, 2010 BSD
Man Page