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;
|
lock->cpu = 0xffffffff;
|
||||||
|
|
||||||
// The xchg serializes, so that reads before release are
|
// The xchg serializes, so that reads before release are
|
||||||
// not reordered after it. (This reordering would be allowed
|
// not reordered after it. The 1996 PentiumPro manual (Volume 3,
|
||||||
// by the Intel manuals, but does not happen on current
|
// 7.2) says reads can be carried out speculatively and in
|
||||||
// Intel processors. The xchg being asm volatile also keeps
|
// any order, which implies we need to serialize here.
|
||||||
// gcc from delaying the above assignments.)
|
// 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);
|
xchg(&lock->locked, 0);
|
||||||
|
|
||||||
popcli();
|
popcli();
|
||||||
|
|
Loading…
Reference in a new issue