Date: Sun, 25 Nov 2007 10:05:37 -0800 From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <deischen@freebsd.org> Cc: Stephan Uphoff <ups@freebsd.org>, cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: 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 Message-ID: <4749B971.3000703@elischer.org> In-Reply-To: <Pine.GSO.4.64.0711251207590.8538@sea.ntplx.net> References: <200711081447.lA8EltXO052057@repoman.freebsd.org> <47492064.7080108@freebsd.org> <Pine.GSO.4.64.0711251207590.8538@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4749B971.3000703>