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>