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

[Robert Watson]

On Sun, 25 Nov 2007, 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.

At least for now, there is significantly different calling convention in using 
an rmlock, as the locker needs to provide persistent storage (usually on the 
stack) between lock and unlock for readers.  The patches to add rmlock support 
to UNIX domain sockets were not simply a question of changing the #define's at 
the top of the file, but instead required changing calling conventions in a 
few places where there was asymetric locking or if a function might drop and 
reacquire the lock.

Robert N M Watson
Computer Laboratory
University of Cambridge