2 * mono-memory-model.h: Mapping of the arch memory model.
5 * Rodrigo Kumpera (kumpera@gmail.com)
7 * (C) 2011 Xamarin, Inc
10 #ifndef _MONO_UTILS_MONO_MEMMODEL_H_
11 #define _MONO_UTILS_MONO_MEMMODEL_H_
14 #include <mono/utils/mono-membar.h>
17 In order to allow for fast concurrent code, we must use fencing to properly order
18 memory access - specially on arch with weaker memory models such as ARM or PPC.
20 On the other hand, we can't use arm's weak model on targets such as x86 that have
21 a stronger model that requires much much less fencing.
23 The idea of exposing each arch memory model is to avoid fencing whenever possible
24 but at the same time make all required ordering explicit.
26 There are four kinds of barriers, LoadLoad, LoadStore, StoreLoad and StoreStore.
27 Each arch must define which ones needs fencing.
29 We assume 3 kinds of barriers are available: load, store and memory (load+store).
31 TODO: Add support for weaker forms of CAS such as present on ARM.
32 TODO: replace all explicit uses of memory barriers with macros from this section. This will make a nicer read of lazy init code.
33 TODO: if we find places where a data depencency could replace barriers, add macros here to help with it
34 TODO: some arch with strong consistency, such as x86, support weaker access. We might need to expose more kinds of barriers once we exploit this.
37 #define MEMORY_BARRIER mono_memory_barrier ()
38 #define LOAD_BARRIER mono_memory_read_barrier ()
39 #define STORE_BARRIER mono_memory_write_barrier ()
49 #if defined(__i386__) || defined(__x86_64__)
51 Both x86 and amd64 follow the SPO memory model:
52 -Loads are not reordered with other loads
53 -Stores are not reordered with others stores
54 -Stores are not reordered with earlier loads
57 /*Neither sfence or mfence provide the required semantics here*/
58 #define STORE_LOAD_FENCE MEMORY_BARRIER
59 #define STORE_RELEASE_FENCE MEMORY_BARRIER
61 #elif defined(__arm__)
63 ARM memory model is as weak as it can get. the only guarantee are data dependent
65 LoadStore fences are much better handled using a data depencency such as:
66 load x; if (x = x) store y;
68 This trick can be applied to other fences such as LoadLoad, but require some assembly:
75 #define STORE_STORE_FENCE STORE_BARRIER
76 #define LOAD_LOAD_FENCE LOAD_BARRIER
77 #define STORE_LOAD_FENCE MEMORY_BARRIER
78 #define LOAD_STORE_FENCE MEMORY_BARRIER
79 #define STORE_RELEASE_FENCE MEMORY_BARRIER
83 /*default implementation with the weakest possible memory model */
84 #define STORE_STORE_FENCE STORE_BARRIER
85 #define LOAD_LOAD_FENCE LOAD_BARRIER
86 #define STORE_LOAD_FENCE MEMORY_BARRIER
87 #define LOAD_STORE_FENCE MEMORY_BARRIER
88 #define STORE_RELEASE_FENCE MEMORY_BARRIER
92 #ifndef STORE_STORE_FENCE
93 #define STORE_STORE_FENCE
96 #ifndef LOAD_LOAD_FENCE
97 #define LOAD_LOAD_FENCE
100 #ifndef STORE_LOAD_FENCE
101 #define STORE_LOAD_FENCE
104 #ifndef LOAD_STORE_FENCE
105 #define LOAD_STORE_FENCE
109 Acquire/release semantics macros.
111 Acquire/release models what most code needs, which is to do load/store pairing of barriers
112 from multiple threads.
113 Release semantics makes sure all stores are visible before any subsequent memory access.
114 Acquire semantics make sure all following loads won't be visible before the current one.
116 This is a slightly harmless variantion on ECMA's that further constraints ordering amongs
117 different kinds of access.
119 #define mono_atomic_store_release(target,value) do { \
120 *(target) = (value); \
121 STORE_RELEASE_FENCE; \
124 /*Makes sure all previous stores as visible before */
125 #define mono_atomic_store_seq(target,value) do { \
127 *(target) = (value); \
131 /*Combines the guarantees of store_release and store_seq.*/
132 #define mono_atomic_store_release_seq(target,value) do { \
133 mono_atomic_store_seq (target, value) \
134 STORE_RELEASE_FENCE; \
138 #define mono_atomic_load_acquire(target) ({ \
139 typeof (*target) __tmp = *target; \
143 #endif /* _MONO_UTILS_MONO_MEMMODEL_H_ */