> From: "Gordon W. Ross" <gwr@mediaone.net>
>
> 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
       call lockmgr().)

       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.

ross.harvey@computer.org