Date: Mon, 01 Nov 1999 10:06:09 -0700 From: "Justin T. Gibbs" <gibbs@freebsd.org> To: nate@mt.sri.com (Nate Williams) Cc: Julian Elischer <julian@whistle.com>, Daniel Eischen <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <199911011706.KAA00397@caspian.plutotech.com> In-Reply-To: Your message of "Sun, 31 Oct 1999 19:19:25 MST." <199911010219.TAA13936@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911011706.KAA00397>