On Saturday 02 September 2006 17:22, Andrew Doran wrote:
> Hi all,
>
> I have been doing a bit of work on the newlock primatives that Jason
> Thorpe added a few years back. I'd appreciate some constructive review
> of the API before I start checking things in. I have put a couple of
> draft manual pages for the primatives here:
>
>  ftp://ftp.netbsd.org/pub/NetBSD/misc/ad/newlock/mutex.txt
>  ftp://ftp.netbsd.org/pub/NetBSD/misc/ad/newlock/rwlock.txt
>
> These would be used to replace splfoo()/simple_lock(), spinlockmgr()
> and outside of VFS, lockmgr().
>
> Note that in the non-DIAGNOSTIC / MULTIPROCESSOR case, the spin locks
> basically boil down to at most splraiseipl()/splx(). The adaptive locks
> remain, however. I don't see that as a big problem: if an architecture
> implements the basic lock stubs, the common case of acquiring or releasing
> a lock is cheap: perhaps 10 or so instructions. For an example of memory
> usage, on i386 a mutex is 4 bytes and a RW lock is 16 bytes.
>
> The *_high() variants are a special case for the guts of the kernel where
> we need to release spin locks out of order. They aren't pretty, and I'm
> not sure if they should be documented for device drivers.
>

I think it is a good idea that you finally implement mutexes on NetBSD.

Some comments:

1) Try to avoid using function/structure names already defined by by the 
FreeBSD mutex implementation, "man mutex", so that one can put an emulation 
layer on top that emulates FreeBSD mutexes on NetBSD.

2) Mutexes must allow recursation.

3) Nice if there are some functions that can drop/pickup the recursation 
count.

4) You need to implement mutex_sleep(), like there is "ltsleep" for 
simplelocks. Try to avoid the function name "msleep()".

--HPS