Subject: Re: SMP API things, take 2
To: Jason Thorpe <>
From: Eduardo E. Horvath <>
List: tech-smp
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

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
	"I need to find a pithy new quote." -- me