From 73f10281ea96d7e8b4fc1c5d755a7c8eb484155b Mon Sep 17 00:00:00 2001 From: Nick Piggin Date: Wed, 14 May 2008 06:35:11 +0200 Subject: read_barrier_depends arch fixlets read_barrie_depends has always been a noop (not a compiler barrier) on all architectures except SMP alpha. This brings UP alpha and frv into line with all other architectures, and fixes incorrect documentation. Signed-off-by: Nick Piggin Acked-by: Paul E. McKenney Signed-off-by: Linus Torvalds --- Documentation/memory-barriers.txt | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'Documentation/memory-barriers.txt') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index e5a819a4f0c..f5b7127f54a 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -994,7 +994,17 @@ The Linux kernel has eight basic CPU memory barriers: DATA DEPENDENCY read_barrier_depends() smp_read_barrier_depends() -All CPU memory barriers unconditionally imply compiler barriers. +All memory barriers except the data dependency barriers imply a compiler +barrier. Data dependencies do not impose any additional compiler ordering. + +Aside: In the case of data dependencies, the compiler would be expected to +issue the loads in the correct order (eg. `a[b]` would have to load the value +of b before loading a[b]), however there is no guarantee in the C specification +that the compiler may not speculate the value of b (eg. is equal to 1) and load +a before b (eg. tmp = a[1]; if (b != 1) tmp = a[b]; ). There is also the +problem of a compiler reloading b after having loaded a[b], thus having a newer +copy of b than a[b]. A consensus has not yet been reached about these problems, +however the ACCESS_ONCE macro is a good place to start looking. SMP memory barriers are reduced to compiler barriers on uniprocessor compiled systems because it is assumed that a CPU will appear to be self-consistent, -- cgit v1.2.3