From be38c8413e1841dc8171555e8da66f3ca8a2e2bb Mon Sep 17 00:00:00 2001
From: rtm <rtm>
Date: Sun, 28 Sep 2008 10:53:54 +0000
Subject: [PATCH] document lock->locked=0 vs xchg(&lock->locked, 0)

---
 spinlock.c | 12 ++++++++----
 1 file 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();
-- 
GitLab