base: memory barriers in lock implementations

The memory barrier prevents the compiler from changing the program order
of memory accesses in such a way that accesses to the guarded resource
get outside the guarded stage. As cmpxchg() defines the start of the
guarded stage it also represents an effective memory barrier.

On x86, the architecture ensures to not reorder writes with older reads,
writes to memory with other writes (except in cases that are not
relevant for our locks), or read/write instructions with I/O
instructions, locked instructions, and serializing instructions.

However on ARM, the architectural memory model allows not only that
memory accesses take local effect in another order as their program
order but also that different observers (components that can access
memory like data-busses, TLBs and branch predictors) observe these
effects each in another order. Thus, a correct program order isn't
sufficient for a correct observation order. An additional architectural
preservation of the memory barrier is needed to achieve this.

Fixes #692
This commit is contained in:
Martin Stein
2014-11-14 10:44:56 +01:00
committed by Christian Helmuth
parent d452f37c25
commit ec6c19a487
12 changed files with 163 additions and 9 deletions

View File

@@ -16,6 +16,7 @@
/* Genode includes */
#include <cpu/atomic.h>
#include <cpu/memory_barrier.h>
#include <base/thread.h>
/* local includes */
@@ -89,7 +90,7 @@ static inline void spinlock_unlock(volatile T *lock_variable)
if (utcb) {
utcb->tls = (((utcb->tls & COUNTER_MASK) + 4) % 4096) & COUNTER_MASK;
/* take care that compiler generates code that writes tls to memory */
asm volatile ("":::"memory");
Genode::memory_barrier();
}
/*