document lock->locked=0 vs xchg(&lock->locked, 0)
This commit is contained in:
parent
0159c8bb94
commit
be38c8413e
1 changed files with 8 additions and 4 deletions
12
spinlock.c
12
spinlock.c
|
@ -54,10 +54,14 @@ release(struct spinlock *lock)
|
|||
lock->cpu = 0xffffffff;
|
||||
|
||||
// The xchg serializes, so that reads before release are
|
||||
// not reordered after it. (This reordering would be allowed
|
||||
// by the Intel manuals, but does not happen on current
|
||||
// Intel processors. The xchg being asm volatile also keeps
|
||||
// gcc from delaying the above assignments.)
|
||||
// not reordered after it. The 1996 PentiumPro manual (Volume 3,
|
||||
// 7.2) says reads can be carried out speculatively and in
|
||||
// any order, which implies we need to serialize here.
|
||||
// But the 2007 Intel 64 Architecture Memory Ordering White
|
||||
// Paper says that Intel 64 and IA-32 will not move a load
|
||||
// after a store. So lock->locked = 0 would work here.
|
||||
// The xchg being asm volatile ensures gcc emits it after
|
||||
// the above assignments (and after the critical section).
|
||||
xchg(&lock->locked, 0);
|
||||
|
||||
popcli();
|
||||
|
|
Loading…
Reference in a new issue