From owner-cvs-src@FreeBSD.ORG Sun Nov 25 17:33:50 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 49DA216A419; Sun, 25 Nov 2007 17:33:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 158F713C465; Sun, 25 Nov 2007 17:33:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2ABAB46B28; Sun, 25 Nov 2007 12:37:16 -0500 (EST) Date: Sun, 25 Nov 2007 17:33:43 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel Eischen In-Reply-To: Message-ID: <20071125173205.B3680@fledge.watson.org> References: <200711081447.lA8EltXO052057@repoman.freebsd.org> <47492064.7080108@freebsd.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: Sun, 25 Nov 2007 17:33:50 -0000 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