From owner-freebsd-arch Sun Oct 31 18:19:49 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 1FFF114E9E for ; Sun, 31 Oct 1999 18:19:45 -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 DAA01205 for ; Mon, 1 Nov 1999 03:19:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69298 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:19:44 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 59C7514BD7 for ; Sun, 31 Oct 1999 18:19:29 -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 TAA08245; Sun, 31 Oct 1999 19:19:26 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id TAA13936; Sun, 31 Oct 1999 19:19:25 -0700 Date: Sun, 31 Oct 1999 19:19:25 -0700 Message-Id: <199911010219.TAA13936@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199910312344.SAA24146@pcnet1.pcnet.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. :) What we did was move away from allowing a thread to aborted prematurely, and made all of our threads check for the existence of a 'aborted' flag. The downside to this is that if the thread is blocked, it will never wake up *unless* you know which resource it's blocked on, at which point you're back to square one. If we had a basic 'interrupt if blocked' mechanism in the threading primitives it might work, such that every thread would be allowed to 'unblock' just to check the flag, but for no other (abnormal) reason. This solution also has an added advantage in that the thread knows the exact context that it was 'aborted' at, and can do proper context saving and/or exception handling based on where it was at, rather than trying to guess at what went wrong. In pigin-Java. thread_start() { // Do the deed // Aquire lock synchronized (mutex) { try { block_waiting_for_something(); } catch (InterruptedException e) { // Someone is trying to get my attention. if (aborted) { // *Sigh* - And I really liked doing this... } return; } // Got whatever something I needed, deal with it.. try { block_waiting_for_something_else(); } catch (InterruptedException e) { // Someone is trying to get my attention. if (aborted) { // *Sigh* - And I really liked doing this... } return; } // Etc.... } I can deal with each blocked resource as necessary, or group them together if it makes more sense... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message