Subject: Re: SMP API (why not use standards?)
To: None <firstname.lastname@example.org, email@example.com>
From: Ross Harvey <firstname.lastname@example.org>
Date: 07/28/1999 21:13:48
> From: "Gordon W. Ross" <email@example.com>
> Why invent a new API for the mutex locks?
> Using mutex_t, mutex_lock(), mutex_unlock(), mutex_trylock, etc.
> in the kernel seems easier to document, at least...
> (and otherwise apparently has identical semantics)
Interesting idea, using posix-like names, but...
1. those have no ipl property (more about ipl's later, but we
will have to diverge from posix for that reason alone)
2. we already have an API in the kernel, and so far it has been
kept almost exactly. The heavy spinlocks are exactly done to
the existing lockmgr() API, except for the new flag LK_SPIN that
means: spin instead of sleep. All the other complex lockmgr()
API elements are unchanged. spinlockmgr() is just a macro to
add LK_SPIN to the lockmgr() call for you. (Something you can
do anyway for once and for all with lockinit(), and then just
The broader meaning of LK_SPIN is that the lock is owned by
a cpu, which brings up...
3. the posix mutexes are owned by threads, but they don't have,
as you point out, a lot of features beyond simple_lock().
I would find it kind of confusing to apply sleeplock or
adaptive mutex terminology to the traditional simple
spinlocks that have been in the kernel since Mach and 4.4.