From owner-freebsd-arch Mon Nov 1 10: 6:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C53BE15035 for ; Mon, 1 Nov 1999 10:06:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA05680 for ; Mon, 1 Nov 1999 19:06:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA74142 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 19:06:16 +0100 (MET) Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 7E95C15009 for ; Mon, 1 Nov 1999 10:06:04 -0800 (PST) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id KAA00397; Mon, 1 Nov 1999 10:06:09 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199911011706.KAA00397@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: nate@mt.sri.com (Nate Williams) Cc: Julian Elischer , Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-reply-to: Your message of "Sun, 31 Oct 1999 19:19:25 MST." <199911010219.TAA13936@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Nov 1999 10:06:09 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > 11.) Ability for the threads library to cancel/terminate a thread >> > blocked in the kernel. >> >> oooooh > >Oooh is right. This has the potential to deadlock the kernel if the >thread owns some sort of 'thread' resources. Justin and I were having a >discussion about this very thing earlier today, and I don't think I was >able to express myself well, so here it goes again. > >Basically, what happens if a particular thread owns a resource that >others are blocking on, and it's woken up 'prematurely'? If the thread >is aborted out of the kernel, the other threads (which might exist in >the kernel) may not be woken up (ever), thus causing zombie threads. > >If you take this further, it's possible that you can introduce deadlock >and/or races very easily when you allow threads to be aborted. >Unfortunately, I'm all too familiar with this problem, having been able >to design a system that all too often exhibits this behavior. :) The solution to these kinds of problems is to provide an exception mechanism for threads that are in the kernel. When you wish to abort a thread, the thread is forced into an exception state and unwinds its stack and the releases its resources in a programmatic fashion. I'm not advocating rewriting the kernel in C++, but adding a C exception mechanism with try/catch type semantics is a very clean way of dealing with these kinds of issues. With PC range tables, you can get this feature with 0 runtime penalty other than having your exception code in core but far removed from your execute path. There are several situations where you really do want to abort threads in a kernel context (even those that are not explicitly sleeping) and whatever solution we devise should allow for it to occur. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message