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.
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
