From 9fd9f80431ad85552c0969831a3ccc3e800ac464 Mon Sep 17 00:00:00 2001
From: rsc <rsc>
Date: Sun, 30 Sep 2007 14:30:04 +0000
Subject: Re: why cpuid() in locking code?

rtm wrote:
> Why does acquire() call cpuid()? Why does release() call cpuid()?

The cpuid in acquire is redundant with the cmpxchg, as you said.
I have removed the cpuid from acquire.

The cpuid in release is actually doing something important,
but not on the hardware.  It keeps gcc from reordering the
lock->locked assignment above the other two during optimization.
(Not that current gcc -O2 would choose to do that, but it is allowed to.)
I have replaced the cpuid in release with a "gcc barrier" that
keeps gcc from moving things around but has no hardware effect.

On a related note, I don't think the cpuid in mpmain is necessary,
for the same reason that the cpuid wasn't needed in release.

As to the question of whether

  acquire();
  x = protected;
  release();

might read protected after release(), I still haven't convinced
myself whether it can.  I'll put the cpuid back into release if
we determine that it can.

Russ
---
 main.c | 1 -
 1 file changed, 1 deletion(-)

(limited to 'main.c')

diff --git a/main.c b/main.c
index 275aa80..2108d95 100644
--- a/main.c
+++ b/main.c
@@ -50,7 +50,6 @@ mpmain(void)
   if(cpu() != mp_bcpu())
     lapic_init(cpu());
   setupsegs(0);
-  cpuid(0, 0, 0, 0, 0);  // memory barrier
   cpus[cpu()].booted = 1;
 
   scheduler();
-- 
cgit v1.2.3