Date: Mon, 1 Nov 1999 12:07:42 -0700 From: Nate Williams <nate@mt.sri.com> To: "Justin T. Gibbs" <gibbs@freebsd.org> Cc: nate@mt.sri.com (Nate Williams), Julian Elischer <julian@whistle.com>, Daniel Eischen <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <199911011907.MAA18241@mt.sri.com> In-Reply-To: <199911011706.KAA00397@caspian.plutotech.com> References: <199911010219.TAA13936@mt.sri.com> <199911011706.KAA00397@caspian.plutotech.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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911011907.MAA18241>