summaryrefslogtreecommitdiff
path: root/spinp
diff options
context:
space:
mode:
authorrsc <rsc>2007-09-30 14:30:04 +0000
committerrsc <rsc>2007-09-30 14:30:04 +0000
commit9fd9f80431ad85552c0969831a3ccc3e800ac464 (patch)
treee9190c3029d9b3eda767ae9d2cb93e0e54344e7b /spinp
parentc840f3ecdc718c4a6eb6fbd9e0cbb0a012c3adf4 (diff)
downloadxv6-labs-9fd9f80431ad85552c0969831a3ccc3e800ac464.tar.gz
xv6-labs-9fd9f80431ad85552c0969831a3ccc3e800ac464.tar.bz2
xv6-labs-9fd9f80431ad85552c0969831a3ccc3e800ac464.zip
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
Diffstat (limited to 'spinp')
0 files changed, 0 insertions, 0 deletions