From owner-freebsd-arch Mon Nov 1 11:13:23 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 6BEC014F2C for ; Mon, 1 Nov 1999 11:13: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 UAA06452 for ; Mon, 1 Nov 1999 20:13:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA74514 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 20:13:16 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 9C6E315031; Mon, 1 Nov 1999 11:07:51 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id MAA16808; Mon, 1 Nov 1999 12:07:43 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA18241; Mon, 1 Nov 1999 12:07:42 -0700 Date: Mon, 1 Nov 1999 12:07:42 -0700 Message-Id: <199911011907.MAA18241@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: nate@mt.sri.com (Nate Williams), Julian Elischer , Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911011706.KAA00397@caspian.plutotech.com> References: <199911010219.TAA13936@mt.sri.com> <199911011706.KAA00397@caspian.plutotech.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) 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. You and I are on the same track here. This is the kind of functionality I would like to see, and I proposed something like that in an email to the group. The only downsides to execption handling is that it often makes your code a bit harder to read if you get really anal about exception handling. :) > 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. Agreed, but it needs to be a 'signal' or an 'exception' to the thread, so the thread itself can unwind, rather than having it abort. That way the thread itself can clean up as it sees fit... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message