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