Bill Sommerfeld wrote:
> 
> > The following functions or macros will be exported by <machine/lock.h>:
> >
> >       void cpu_simple_lock_init(__volatile struct simplelock *alp);
> >       void cpu_simple_lock(__volatile struct simplelock *alp);
>                         while (alp->lock_data != 0) /* spin */;
>                         alp->lock_data = 1;
> 
> >       int cpu_simple_lock_try(__volatile struct simplelock *alp);
> >       void cpu_simple_unlock(__volatile struct simplelock *alp);
> ...
> 
> >                       alp->lock_data = 0;
> 
> Is the intent here that lock_data always be "1" for locked and "0" for
> unlocked?  Is it intended to be OK for code to examine lock_data
> directly?  or should only cpu_simple_lock_try be used for that?

I think that struct simplelock should be opaque and only
cpu_simple_lock_try
should be used for examination (else the result is worthless anyway ...)
Especially on a HP you don't want people to access it directly anyway
(AFAIK
there are some cache issues even when your only reading it).


Also I would suggest that we also blocks interrupts always (or have a
field in
the lock for the int-level) else debugging will become a nightmare
(deadlocks in interrupts). 

These spin locks should never protect longer parts of code, so it
shouldn't be an issue.

Stefan

> 
> On one architecture I'm aware of, it's more convenient for "0" to mean
> locked and "1" to mean unlocked (PA-RISC, which does have MP systems;
> also, some people have expressed interest in a port to the PA in the
> past).
>                                                 - Bill

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