summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorrtm <rtm>2008-09-28 10:53:54 +0000
committerrtm <rtm>2008-09-28 10:53:54 +0000
commitbe38c8413e1841dc8171555e8da66f3ca8a2e2bb (patch)
tree30d80ef132221e6bd253f7f54995ea70b2a1ffc1
parent0159c8bb941772d91537037ff2489a9261d740ca (diff)
downloadxv6-labs-be38c8413e1841dc8171555e8da66f3ca8a2e2bb.tar.gz
xv6-labs-be38c8413e1841dc8171555e8da66f3ca8a2e2bb.tar.bz2
xv6-labs-be38c8413e1841dc8171555e8da66f3ca8a2e2bb.zip
document lock->locked=0 vs xchg(&lock->locked, 0)
-rw-r--r--spinlock.c12
1 files changed, 8 insertions, 4 deletions
diff --git a/spinlock.c b/spinlock.c
index ba5bb4a..5f04dcf 100644
--- a/spinlock.c
+++ b/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();