1membar_ops(9F) Kernel Functions for Drivers membar_ops(9F)
2
6 membar_ops, membar_enter, membar_exit, membar_producer, membar_consumer
7 - memory access synchronization barrier operations
8
10 #include <sys/atomic.h>
11 void membar_enter(void);
13 void membar_exit(void);
16 void membar_producer(void);
19 void membar_consumer(void);
22
25 The membar_enter() function is a generic memory barrier used during
26 lock entry. It is placed after the memory operation that acquires the
27 lock to guarantee that the lock protects its data. No stores from after
28 the memory barrier will reach visibility and no loads from after the
29 barrier will be resolved before the lock acquisition reaches global
30 visibility.
31 The membar_exit() function is a generic memory barrier used during lock
34 exit. It is placed before the memory operation that releases the lock
35 to guarantee that the lock protects its data. All loads and stores
36 issued before the barrier will be resolved before the subsequent lock
37 update reaches visibility.
38 The membar_enter() and membar_exit() functions are used together to
41 allow regions of code to be in relaxed store order and then ensure that
42 the load or store order is maintained at a higher level. They are use‐
43 ful in the implementation of mutex exclusion locks.
44 The membar_producer() function arranges for all stores issued before
47 this point in the code to reach global visibility before any stores
48 that follow. This is useful in producer modules that update a data
49 item, then set a flag that it is available. The memory barrier guaran‐
50 tees that the available flag is not visible earlier than the updated
51 data, thereby imposing store ordering.
52 The membar_consumer() function arranges for all loads issued before
55 this point in the code to be completed before any subsequent loads.
56 This is useful in consumer modules that check if data is available and
57 read the data. The memory barrier guarantees that the data is not sam‐
58 pled until after the available flag has been seen, thereby imposing
59 load ordering.
60
62 No values are returned.
63
65 No errors are defined.
66
68 These functions can be called from user, interrupt, or kernel context.
69
71 See attributes(5) for descriptions of the following attributes:
72 ┌─────────────────────────────┬─────────────────────────────┐
77 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
78 ├─────────────────────────────┼─────────────────────────────┤
79 │Interface Stability │Committed │
80 └─────────────────────────────┴─────────────────────────────┘
81
83 atomic_add(9F), atomic_and(9F), atomic_bits(9F), atomic_cas(9F),
84 atomic_dec(9F), atomic_inc(9F), atomic_ops(9F), atomic_or(9F),
85 atomic_swap(9F), attributes(5), atomic_ops(3C)
86
88 Atomic instructions (see atomic_ops(9F)) ensure global visibility of
89 atomically-modified variables on completion. In a relaxed store order
90 system, this does not guarantee that the visibility of other variables
91 will be synchronized with the completion of the atomic instruction. If
92 such synchronization is required, memory barrier instructions must be
93 used.
94SunOS 5.11 16 Jan 2006 membar_ops(9F)