"Eduardo E. Horvath" wrote:
> 
> This may be a bit out of date considering the message about adding spl()
> to simple_lock() but here goes:
> 
> On Thu, 29 Jul 1999, Jason Thorpe wrote:
> 
> Do we still need:
> 
> >       u_long cpu_number(void);
> 
> if we have:
> 
> >       struct cpu_info *curcpu(void);
> 
> I suppose that cpu_number could become:
> 
> #define cpu_number      curcpu()->ci_cpuid

with curcpu() defined as cpuinfo[__curcpu] ???

On 386 (and a lot of other machines) curcpu is reading a variable (on a
386
it's on a address on the processor itself). 

So let the MD code define cpu_number.


> 
> One thing that always bothered me about this is that the lock is
> initialized to the unlocked state, which means there's a hole where some
> other thread could try to grab the lock right after it's initialized.  I
> would be happier if it initialized the lock to SIMPLELOCK_LOCKED.
> 

There coud be  a initialize_locked, for those cases where it makes a
difference.

But so far it doesn't be at this level. The cpu locks are only used to 
create the simple locks. So at the moment the usage of them is well
known. 
Stefan

> =========================================================================
> Eduardo Horvath                         eeh@one-o.com
>         "I need to find a pithy new quote." -- me

-- 
Stefan Grefen                                Tantau Software
International Inc.
stefan.grefen@tantau.com 
 --- Hacking's just another word for nothing left to kludge. ---