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
Daniel Eischen
deischen at freebsd.org
Sun Nov 25 09:31:04 PST 2007
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.
--
DE
More information about the cvs-all
mailing list