Date: Sun, 31 Oct 1999 19:19:25 -0700 From: Nate Williams <nate@mt.sri.com> To: Julian Elischer <julian@whistle.com> Cc: Daniel Eischen <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <199911010219.TAA13936@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9910311727080.8816-100000@home.elischer.org> References: <199910312344.SAA24146@pcnet1.pcnet.com> <Pine.BSF.4.05.9910311727080.8816-100000@home.elischer.org>
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. :) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911010219.TAA13936>