Subject: Re: SMP API things, take 2
To: Jason Thorpe <email@example.com>
From: Eduardo E. Horvath <firstname.lastname@example.org>
Date: 07/29/1999 18:42:06
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
> int cpu_lock_spl(int);
> This function, inline function, or macro performs
> the appropriate spl*() operation according to
> the provided LK_SPL_* token (see below). Its return
> value will be passed to splx().
I do not understand this at all. This is a replacement of splx()? What
does it have to do with locks?
I'm not entirely happy about this. I would like to use CASX to store a
pointer to the proc that's attempting to grab the lock (to aid debugging).
Rather than directly comparing them as values I think it would be more
general to have macros that take a pointer to a lock and return true or
#define SIMPLELOCK_LOCKED(l) ((l)->lock_data != 0)
(NB: better than using __aligned would be to have the type of lock_data
defined in <machine/lock.h>.)
> The following functions or macros will be exported by <machine/lock.h>:
> void cpu_simple_lock_init(__volatile struct simplelock *alp);
> This function, inline function, or macro initializes
> the `lock_data' member of `struct simplelock' to the
> value SIMPLELOCK_UNLOCKED.
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.
Eduardo Horvath email@example.com
"I need to find a pithy new quote." -- me