From owner-cvs-all@FreeBSD.ORG Sat Mar 10 20:54:09 2007 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1865116A402; Sat, 10 Mar 2007 20:54:09 +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 5BA4513C4A7; Sat, 10 Mar 2007 20:54:07 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E1E56487F5; Sat, 10 Mar 2007 21:54:05 +0100 (CET) Received: from localhost (p42220-ipbffx02marunouchi.tokyo.ocn.ne.jp [211.129.152.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3064E456AB; Sat, 10 Mar 2007 21:53:57 +0100 (CET) Date: Sat, 10 Mar 2007 21:52:36 +0100 From: Pawel Jakub Dawidek To: Attilio Rao Message-ID: <20070310205236.GA9185@garage.freebsd.pl> References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703091747.07617.jhb@freebsd.org> <3bbf2fe10703100344w1f2464f0q68086a5af7c4f63c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <3bbf2fe10703100344w1f2464f0q68086a5af7c4f63c@mail.gmail.com> 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=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, John Baldwin Subject: Re: cvs commit: src/share/man/man9 Makefile condvar.9 lock.9 mi_switch.9 mtx_pool.9 mutex.9 rwlock.9 sleep.9 sleepqueue.9 sx.9 thread_exit.9 src/sys/kern kern_synch.c src/sys/sys mutex.h rwlock.h sleepqueue.h sx.h systm.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2007 20:54:09 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 10, 2007 at 12:44:26PM +0100, Attilio Rao wrote: > 2007/3/9, John Baldwin : > >I don't have a date set for removing msleep(), esp. given it's wide use. > >I would like to remove it and all the spl*() functions in 8.0 if we can > >swing it. > > > >I also have patches to let condition variables work with rwlocks and sx > >locks, but the current implementation results in an API "explosion" > >since each of the cv_*wait*() functions grows a cv_*wait*_rw() version f= or > >rwlocks and a cv_*waut*_sx() version for use with sx locks. One possibi= lity > >would be to just cast the lock argument to (struct lock_object *) since = all > >of our locks have a lock_object as the first member, but then you use ha= ving > >the compiler do type checking, and I'm really not willing to give up on > >that. Too easy to have evil bugs that way. I suppose we could use some > >evil macro that used typeof() but that would be very gcc specific? > > > >I guess one other possibility is to standardize on the field name for > >the lock_object, calling it lo_object instead of mtx_object, rw_object, > >sx_object, etc. Anyone else have any ideas? >=20 > What about adding a new function like: >=20 > static __inline struct lock_object * > mtx_export_lc(struct mtx *m) > { >=20 > return (&m->mtx_object); > } >=20 > to be per-interface (so having sx_export_lc() and rw_export_lc() too) > and than using in this way: >=20 > static struct mtx foo_lock; > static struct cv foo_cv; > ... >=20 > mtx_lock(&foo_lock); > ... > cv_wait(&foo_cv, mtx_export_lc(&foo_lock)); >=20 > (obviously using new struct lock_object methods you added for locking/unl= ocking) >=20 > It sounds reasonable to you? This is ugly. If we really need to provide information about which type of lock we are using, I'd probably prefer cv_wait_(). What about something like this: #define cv_wait(cv, lock) do { switch (LO_CLASSINDEX((struct lock_object *)(lock))) { case 1: cv_wait_mtx(cv, lock); break; case 2: cv_wait_sx(cv, lock); break; case 3: cv_wait_rw(cv, lock); break; default: panic("Invalid lock."); } } while (0) Of course magic values should be replaced, but you get the point. PS. I'd really like to be able to use condvar(9) with sx(9) locks, because currently I've to manage mu own condvar(9) version for ZFS that does exactly this. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF8xqUForvXbEpPzQRAsJwAJ4/rTRjOmna173ToHJv89baYQT8wgCfb1LM YcfgHtQ29Gw1fJxPTipDGbQ= =xXhu -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND--