cvs commit: src/share/man/man9 locking.9 rmlock.9 src/sys/conf files src/sys/kern kern_rmlock.c subr_lock.c subr_pcpu.c subr_smp.c src/sys/sys _rmlock.h lock.h pcpu.h rmlock.h smp.h

[Julian Elischer]

Daniel Eischen wrote:
> On Sat, 24 Nov 2007, Darren Reed wrote:
> 
>> Stephan Uphoff wrote:
>>> ups         2007-11-08 14:47:55 UTC
>>>
>>>   FreeBSD src repository
>>>
>>>   Modified files:
>>>     share/man/man9       locking.9     sys/conf             files 
>>> sys/kern             subr_lock.c subr_pcpu.c subr_smp.c     sys/sys 
>>> lock.h pcpu.h smp.h   Added files:
>>>     share/man/man9       rmlock.9     sys/kern             
>>> kern_rmlock.c sys/sys              _rmlock.h rmlock.h   Log:
>>>   Initial checkin for rmlock (read mostly lock) a multi reader single 
>>> writer
>>>   lock optimized for almost exclusive reader access. (see also rmlock.9)
>>>
>>
>> Is there a white paper or other documentation around somewhere that
>> discusses the benefits/tradeoffs with using rmlock vs rwlock?
> 
> Why aren't we using the rwlock interfaces, but just allowing a different
> behavior when the lock is created (rwlock_init2() or something)?  It
> would seem simpler to keep the same interface and allow easy toggling
> between rwlocks and rmlocks.  The same way we can initialize kernel
> mutexes differently (MTX_DEF, MTX_SPIN) could be applied here.
> 

I think that If anything, we should be going in the other direction..
firstly, mutexes are just rw_locks with no readers. So we might
as well make them the same thing..
Spin and blocking mutexes should in my opinion be defined as 
different structures, at least in name so that the compiler 
hits you with a clue-bat when you try use a spin-lock with non-spinlock 
ops etc.

not sure why sx-locks exist at all, as they seem to be a variant of sleep.
I think it's just a convenience function set to allow one to implement
a sleep-derived synchronisation.