From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 04:29:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E1AA16A409; Wed, 14 Mar 2007 04:29:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id CD6FE13C45B; Wed, 14 Mar 2007 04:29:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2BA00487F4; Wed, 14 Mar 2007 05:29:35 +0100 (CET) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D740D45685; Wed, 14 Mar 2007 05:29:29 +0100 (CET) Date: Wed, 14 Mar 2007 05:29:26 +0100 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20070314042926.GA6013@garage.freebsd.pl> References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> <45F771E2.9050709@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <45F771E2.9050709@elischer.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Robert Watson , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 04:29:37 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2007 at 08:54:10PM -0700, Julian Elischer wrote: > Julian Elischer wrote: >=20 > >ok so how about I commit this to get us started and the nroff and > >locking experts can take it from there. >=20 > The first table I think may look like this (from quick reading.. but I ma= y be wrong): >=20 >=20 > The following table shows what you can and can not do if you hold one= of > the synchronisation primatives discussed here: (someone who knows what > they are talking about should write this table) I think it should be: > You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep > SPIN mutex ok no no no no-3 > Sleep mutex ok ok-1 no ok no-3 > sx_lock ok no ?? no ok-4 sx_lock ok ok ok-2 ok ok > rw_lock ok no no ok-2 no-3 rw_lock ok ok no ok-2 no And I'd sort the table a bit differently: spin, mtx, rw, sx[, sleep]. > *1 Recursion is defined per lock. lock order is important. Lock order is always important, not only between the same lock types. You also can't mix order of acquiring mtx and rw locks, etc. > *2 readers can recurse tough writers can not. lock order is important. I think John or Attilio are working on adding a flag which will allow for recursion. > *3 There are calls atomically release this primative when going to sl= eep > and reacquire it on wakeup (e.g. mtx_sleep(), rw-sleep() and > msleep_spin).() >=20 > *4 One can also use sx_sleep() which atomically release this primative > when going to sleep and reacquire it on wakeup. What's the difference between 3 and 4? {rw,sx}_sleep(9) fucntions are quite new and I don't know if you can use then only while writer/exclusive lock or also while holding reader/shared lock. BTW. I just wake up with a feeling that I did something wrong in my code. I thought about it for a moment and it seems I'm right. When one always use rw/sx locks this way: sx_xlock(); /* do work */ sx_downgrade(); /* do work */ sx_sunlock(); (the same for rw(9)) the lock will _never_ be shared, because one still always acquire exclusive lock first, which serialize synchronization. Is my thinking correct? If so, I think it's not very obvious, so we may want to add a comment about such use to the manual page as well. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF93omForvXbEpPzQRAgxjAJ9gw0ez5JupJhX0JxcFSp/UywlfyQCfTrqR XBOJcq5ydkK7I4GB3HzPl9w= =L4vQ -----END PGP SIGNATURE----- --ibTvN161/egqYuK8--