From owner-cvs-src@FreeBSD.ORG Mon Nov 26 10:17:10 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 3CF2F16A41B for ; Mon, 26 Nov 2007 10:17:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id AD51313C45D for ; Mon, 26 Nov 2007 10:17:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so607156nfb for ; Mon, 26 Nov 2007 02:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=zP+3dYWAwv381J5PfvTnFQK9OrglM+A7OxcVc9Tl780=; b=wLk5yPvTpUGdYouUPNYh0dhkFxi2yuk9j6uFdFUXh9cs5JaBt4Bwczbtn1iPcwnrLaj1xmyYtqvJGbAxBz2SimxI1bLVWucNh+CEadcb6+GL0ANBZr/as3ZmGRXOn5GiOe45dY2CdmNLQlucHYCi9mNYujvotHCZbzYOjBR9ja8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Zd/qskleUTpkmhirec/zICkzrXgTi/loS4qvuK+tTp4GpBxraY1VoaC3/xuuNK9HwXBUjxNHnflrX4mEwXoSDEredBXqtDlhXkAxe3eBnh5jYJjeRoAs+xmtLVkZPq9bgxRGLgbFsBiGftwYSeo7Vz1RQbkbNXuuNFxXsmJgNcI= Received: by 10.86.95.20 with SMTP id s20mr2542829fgb.1196072226344; Mon, 26 Nov 2007 02:17:06 -0800 (PST) Received: by 10.86.28.19 with HTTP; Mon, 26 Nov 2007 02:17:06 -0800 (PST) Message-ID: <3bbf2fe10711260217p45362826wc03c7f4ee3d224a@mail.gmail.com> Date: Mon, 26 Nov 2007 11:17:06 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Daniel Eischen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711081447.lA8EltXO052057@repoman.freebsd.org> <47492064.7080108@freebsd.org> <4749B971.3000703@elischer.org> X-Google-Sender-Auth: 2a52c560e27c3c17 Cc: src-committers@freebsd.org, current@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, Julian Elischer , Stephan Uphoff 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 10:17:10 -0000 2007/11/26, Daniel Eischen : > 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 :-) If you are referring to our implementation, CVs get rwlock and sxlock as well. They could theorically get rmlock as well, but currently locking / unlocking operations aren't still implemented in the generic layer. > > 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. Well, honestly spin-mutex should never be used on consumer code. They should be used only in very special contexts (like fast handler / interrupt filter) or however code running in kernel context. Generally, we discourage their usage (just consider CV, callout and sleep_* don't support them) at higher lever than necessary. I see a usual mistake cames from people porting Linux drivers and using it, even when not necessary. Maybe we should have a clearer documentation on how using netbus methods and what locking should be in their regards? > > 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? rmlock are like rwlock from a low level perspective, but they are very different from sxlock. rmlock and rwlock use turnstiles as back-end primitive for blocking threads and handling wakeup event. sxlock use sleepqueues as back-end primitive and they are, as rightly expressed here, a variant of sleeping which handle sleep / wakeup efficiently. Some rules about locking should be: - Prefer always primitives using turnstiles as back-end (so mutex, rwlock and rmlock) - Try to not recurse, except than in rare cases - Try to maintain limitated usage of sxlock and spinlock These rules in practice are applied not in a strong way. Attilio -- Peace can only be achieved by understanding - A. Einstein