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