From owner-cvs-src@FreeBSD.ORG Mon Nov 26 05:46:19 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C14F816A418; Mon, 26 Nov 2007 05:46:19 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2C413C43E; Mon, 26 Nov 2007 05:46:19 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lAQ5VMYE023590; Mon, 26 Nov 2007 00:31:23 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 26 Nov 2007 00:31:23 -0500 (EST) Date: Mon, 26 Nov 2007 00:31:22 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <4749B971.3000703@elischer.org> Message-ID: References: <200711081447.lA8EltXO052057@repoman.freebsd.org> <47492064.7080108@freebsd.org> <4749B971.3000703@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Stephan Uphoff , 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 05:46:20 -0000 On Sun, 25 Nov 2007, Julian Elischer wrote: > 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.. Robert already answered my question sufficiently... I am looking at the way Solaris does its kernel synchronizations. They have mutexes, CVs, and rwlocks as far as I can see. It is very convenient to have mutexes and CVs just as their userland counterparts. Mutexes are mutual exclusion and by definition not rwlock-capable. You don't want to mix the mutex API with the rwlock or rmlock APIs, and also, the CV APIs (cv_waitXXX, cv_timedwaitXXX) only take mutex types as arguments. If the implementations can share code, ok, but don't share the mutex/CV APIs with the r{mw}lock APIs :-) > 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. That seems nice, but doesn't go along well with trying to keep a similar API as Solaris. It is convenient to share the APIs so that it is easy to change the mtx_init() from a default to a spin type without changing the rest of the code. We really shouldn't have a need for spin mutexes if the default mutexes are adaptive, and if mutexes taken by interrupt handlers are initialized in a manner similar to Solaris. There really shouldn't be a separate API for spin mutexes. Once a mutex is initialized as MTX_DEF or MTX_SPIN, that should be sufficient. > 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. Hmm, sx locks seem similar to rmlocks, at least according to the description: Shared/exclusive locks are used to protect data that are read far more often than they are written. Do we need both? -- DE