From owner-freebsd-arch@FreeBSD.ORG Wed Aug 17 12:49:36 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E59E316A41F for ; Wed, 17 Aug 2005 12:49:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37FD243D46 for ; Wed, 17 Aug 2005 12:49:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11481 invoked from network); 17 Aug 2005 12:49:35 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Aug 2005 12:49:33 -0000 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j7HCnOh8034383; Wed, 17 Aug 2005 08:49:24 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 17 Aug 2005 08:36:04 -0400 User-Agent: KMail/1.8 References: <42F9ECF2.8080809@freebsd.org> <200508161716.44597.jhb@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200508170836.05861.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Cc: gnn@FreeBSD.org Subject: Re: Special schedulers, one CPU only kernel, one only userland X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2005 12:49:36 -0000 On Tuesday 16 August 2005 10:13 pm, gnn@freebsd.org wrote: > At Tue, 16 Aug 2005 16:22:41 -0700, > > luigi wrote: > > ok just for the records, the issue i had in mind is the release/acquire > > the mutex around some code that might cause a deadlock, not for the > > mutex ops per se, but for the need to make sure that the data > > structure is consistent before releasing the lock, and rechecking > > the state afterwards. Basically: > > > > 1 mtx_lock(&foo) > > 2 .. work on obj_foo > > 3 .. make obj_foo consistent > > 4 mtx_unlock(&foo) > > 5 f() > > 6 mtx_lock(&foo) > > 7 .. revalidate state of obj_foo > > 8 .. more work > > > > where f() is the call that might sleep or cause a deadlock. > > In cases where f() has a low probability of blocking, we could > > save a bit of work at runtime by writing the code as below: > > > > 1 mtx_lock(&foo) > > 2 .. work on obj_foo > > if (try_f_without_blocking() =3D=3D EWOULDBLOCK) { > > 3 .. make obj_foo consistent > > 4 mtx_unlock(&foo) > > 5 f() > > 6 mtx_lock(&foo) > > 7 .. revalidate state of obj_foo > > } > > 8 .. more work > > > > (where try_f_without_blocking() is a version of f() that returns > > EWOULDBLOCK in case the 'other' lock is busy). > > Here maybe we would benefit by some support (macros, whatever) that > > permits us to specify in a compact way what to do around f() should > > it become blocking. > > > > On the other hand, maybe the instances of code as the one above > > are so rare that there is hardly any need for that. > > Correct me if I'm wrong but I suspect you're thinking of cases such > as: > > RT_UNLOCK(rt); /* XXX workaround LOR */ > gwrt =3D rtalloc1(gate, 1, 0); > RT_LOCK(rt); > > in the routing/networking code. A quick, and by no means exhaustive, > check of CURRENT with cscope and Emacs looking for these turned up 3. > It may still be something to look at, but perhaps mroe from a point of > view of cleaning up our APIs to not do this kind of jiggery pokery, > rather than inventing a new locking paradigm, which is fraught with > peril. > > This isn't exhaustive though, if others can show this kind of thing > being done a lot, or becoming a idiom in our code, then there is more > cause for concern. > > Just my 2 yen :-) Agreed. I'd rather that we fix our APIs and try to organize the workflow t= o=20 minimize the number of times that a lock has to be dropped and then=20 reacquired. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org