aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/memory-barriers.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/memory-barriers.txt')
-rw-r--r--Documentation/memory-barriers.txt12
1 files changed, 11 insertions, 1 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index e5a819a4f0c9..f5b7127f54ac 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -994,7 +994,17 @@ The Linux kernel has eight basic CPU memory barriers:
994 DATA DEPENDENCY read_barrier_depends() smp_read_barrier_depends() 994 DATA DEPENDENCY read_barrier_depends() smp_read_barrier_depends()
995 995
996 996
997All CPU memory barriers unconditionally imply compiler barriers. 997All memory barriers except the data dependency barriers imply a compiler
998barrier. Data dependencies do not impose any additional compiler ordering.
999
1000Aside: In the case of data dependencies, the compiler would be expected to
1001issue the loads in the correct order (eg. `a[b]` would have to load the value
1002of b before loading a[b]), however there is no guarantee in the C specification
1003that the compiler may not speculate the value of b (eg. is equal to 1) and load
1004a before b (eg. tmp = a[1]; if (b != 1) tmp = a[b]; ). There is also the
1005problem of a compiler reloading b after having loaded a[b], thus having a newer
1006copy of b than a[b]. A consensus has not yet been reached about these problems,
1007however the ACCESS_ONCE macro is a good place to start looking.
998 1008
999SMP memory barriers are reduced to compiler barriers on uniprocessor compiled 1009SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
1000systems because it is assumed that a CPU will appear to be self-consistent, 1010systems because it is assumed that a CPU will appear to be self-consistent,