Subject: Re: SMP API things, lock debugging, etc.
To: Bill Sommerfeld <firstname.lastname@example.org>
From: Stefan Grefen <Stefan.Grefen@tantau.com>
Date: 07/27/1999 19:19:28
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
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
there are some cache issues even when your only reading it).
Also I would suggest that we also blocks interrupts always (or have a
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.
> 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
> - Bill
Stefan Grefen Tantau Software
--- Hacking's just another word for nothing left to kludge. ---