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
Change pushcli / popcli so that they can never turn on
interrupts unexpectedly. That is, if interrupts are on,
then pushcli(); popcli(); turns them off and back on, but
if they are off to begin with, then pushcli(); popcli(); is
a no-op.
I think our fundamental mistake was having a primitive
(release and then popcli nee spllo) that could turn
interrupts on at unexpected moments instead of being
explicit about when we want to start allowing interrupts.
With the new semantics, all the manual fiddling of ncli
to force interrupts off in certain sections goes away.
In return, we must explicitly mark the places where
we want to enable interrupts unconditionally, by calling sti().
There is only one: inside the scheduler loop.
