mb_read(9) [netbsd man page]
MB(9) BSD Kernel Developer's Manual MB(9) NAME
mb, mb_memory, mb_read, mb_write -- memory barriers SYNOPSIS
#include <sys/lock.h> void mb_memory(void); void mb_read(void); void mb_write(void); DESCRIPTION
Many types of processor can execute instructions in a different order than issued by the compiler or assembler. On a uniprocessor system, out of order execution is transparent to the programmer, operating system and applications, as the processor must ensure that it is self con- sistent. On multiprocessor systems, out of order execution can present a problem where locks are not used to guarantee atomicity of access, because loads and stores issued by any given processor can appear on the system bus (and thus appear to other processors) in an unpredictable order. mb_memory(), mb_read(), and mb_write() can be used to control the order in which memory accesses occur, and thus the order in which those accesses become visible to other processors. They can be used to implement ``lockless'' access to data structures where the necessary bar- rier conditions are well understood. Memory barriers can be computationally expensive, as they are considered ``serializing'' operations and may stall further execution until the processor has drained internal buffers and re-synchronized. The memory barrier primitives control only the order of memory access. They provide no guarantee that stores have been flushed to the bus, or that loads have been made from the bus. The memory barrier primitives are guaranteed only to prevent reordering of accesses to main memory. They do not provide any guarantee of ordering when used with device memory (for example, loads or stores to or from a PCI device). To guarantee ordering of access to device mem- ory, the bus_dma(9) and bus_space(9) interfaces should be used. FUNCTIONS
mb_memory() Issue a full memory barrier, ordering all memory accesses. Causes all loads and stores preceding the call to mb_memory() to complete before further memory accesses can be made. mb_read() Issue a read memory barrier, ordering all loads from memory. Causes all loads preceding the call to mb_read() to complete before fur- ther loads can be made. Stores may be reordered ahead of or behind a call to mb_read(). mb_write() Issue a write memory barrier, ordering all stores to memory. Causes all stores preceding the call to mb_write() to complete before further stores can be made. Loads may be reordered ahead of or behind a call to mb_write(). SEE ALSO
__insn_barrier(3), bus_dma(9), bus_space(9), mutex(9), rwlock(9) HISTORY
The memory barrier primitives first appeared in NetBSD 5.0. BSD
January 2, 2011 BSD
Check Out this Related Man Page
membar_ops(3C) membar_ops(3C) NAME
membar_ops, membar_enter, membar_exit, membar_producer, membar_consumer - memory access synchronization barrier operations SYNOPSIS
#include <atomic.h> void membar_enter(void); void membar_exit(void); void membar_producer(void); void membar_consumer(void); The membar_enter() function is a generic memory barrier used during lock entry. It is placed after the memory operation that acquires the lock to guarantee that the lock protects its data. No stores from after the memory barrier will reach visibility and no loads from after the barrier will be resolved before the lock acquisition reaches global visibility. The membar_exit() function is a generic memory barrier used during lock exit. It is placed before the memory operation that releases the lock to guarantee that the lock protects its data. All loads and stores issued before the barrier will be resolved before the sub- sequent lock update reaches visibility. The membar_enter() and membar_exit() functions are used together to allow regions of code to be in relaxed store order and then ensure that the load or store order is maintained at a higher level. They are useful in the implementation of mutex exclusion locks. The membar_producer() function arranges for all stores issued before this point in the code to reach global visibility before any stores that follow. This is useful in producer modules that update a data item, then set a flag that it is available. The memory barrier guaran- tees that the available flag is not visible earlier than the updated data, thereby imposing store ordering. The membar_consumer() function arranges for all loads issued before this point in the code to be completed before any subsequent loads. This is useful in consumer modules that check if data is available and read the data. The memory barrier guarantees that the data is not sampled until after the available flag has been seen, thereby imposing load ordering. No values are returned. No errors are defined. See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Interface Stability |Stable | +-----------------------------+-----------------------------+ |MT-Level |MT-Safe | +-----------------------------+-----------------------------+ atomic_add(3C), atomic_and(3C), atomic_bits(3C), atomic_cas(3C), atomic_dec(3C), atomic_inc(3C), atomic_ops(3C), atomic_or(3C), atomic_swap(3C), attributes(5), atomic_ops(9F) Atomic instructions (see atomic_ops(3C)) ensure global visibility of atomically-modified variables on completion. In a relaxed store order system, this does not guarantee that the visibility of other variables will be synchronized with the completion of the atomic instruction. If such synchronization is required, memory barrier instructions must be used. 14 Feb 2005 membar_ops(3C)