diff options
| author | rtm <rtm> | 2008-09-28 10:53:54 +0000 | 
|---|---|---|
| committer | rtm <rtm> | 2008-09-28 10:53:54 +0000 | 
| commit | be38c8413e1841dc8171555e8da66f3ca8a2e2bb (patch) | |
| tree | 30d80ef132221e6bd253f7f54995ea70b2a1ffc1 | |
| parent | 0159c8bb941772d91537037ff2489a9261d740ca (diff) | |
| download | xv6-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.c | 12 | 
1 files changed, 8 insertions, 4 deletions
| @@ -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(); | 
