From owner-freebsd-arch@FreeBSD.ORG Wed Aug 17 04:03:44 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 842CE16A41F for ; Wed, 17 Aug 2005 04:03:44 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EA3943D48 for ; Wed, 17 Aug 2005 04:03:43 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j7H42BDZ076984; Tue, 16 Aug 2005 21:02:11 -0700 (PDT) Date: Wed, 17 Aug 2005 11:13:40 +0900 Message-ID: From: gnn@freebsd.org To: Luigi Rizzo In-Reply-To: <20050816162241.A74005@xorpc.icir.org> References: <42F9ECF2.8080809@freebsd.org> <20050816051231.D66550@xorpc.icir.org> <20050816200010.GJ13959@cirb503493.alcatel.com.au> <200508161716.44597.jhb@FreeBSD.org> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-arch@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 04:03:44 -0000 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() == 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 = 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 :-) Later, George