Gracefully killing a blocked thread

NTDEV
21

Hi Deepu,

Second Generic Answer for ur question:

Generic Answer for your Generic question :), invalidate the object whatever is there on which the thread is waiting :), rt? So just do that.

 

Good Luck,



From: “Deepu.L.R”

>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: Re: [ntdev] Gracefully killing a blocked thread
>Date: Sat, 31 Jan 2004 09:17:32 +0530
>
>hi all…
>
>thanks for all the replies…
>
>Max,Chuck,benson
>
>I asked the question in the usermode point of view and it is a generic
>question. I understood that the usage of TerminateThread() is not encouraged
>and its disadvantages.
>
> > The best you can do is an APC-type mechanism (what we called ‘Ring
> > Alarm’ on Multics) which allows the kernel to bust a thread out of any
> > kernel wait-state and cause it to deliver a signal on return to the user
> > environment. This is good enough for any half-decently-designed
>
>yes, i am asking whether windows supports anything as said above which will
>invoke a thread out of any kernal wait state?[this is generic question and i
>am not trying find solution for a particular problem]
>
>thanks
>Deepu.L.R
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

Contact brides & grooms FREE! Only on www.shaadi.com. Register now!

22

OK, actual experts.

I’ve seen passing mention of a user-mode APC mechanism on Windows. Does
this include something like Unix ‘kill’ that forces a target thread to
return from the kernel and deliver a structured exception?

23

Agreed, but how do you handle the case where your driver is blocked in a
lower-level driver and is never going to come back, because the lower level
driver or device is broke, and you didn’t have any control over what it
waited on?

(Just to throw some petrol on the fire…)

Loren

----- Original Message -----
From: “Chuck Batson”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 29, 2004 9:51 AM
Subject: Re: [ntdev] Gracefully killing a blocked thread

> You should have a sync. object that is yours, a unique one per thread
> if necessary (i.e. if you want per-thread abortion control), that is
> used to abort any and all waits in a thread. The point being that your
> thread should never be able to hang indefinitely on any particular wait
> (because you can exit any particular wait by signalling the appropriate
> abort sync. object), and give the thread a chance to clean up before
> terminating.
>
> Chuck
>
> ----- Original Message -----
> From: “Moreira, Alberto”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, January 30, 2004 12:27 AM
> Subject: RE: [ntdev] Gracefully killing a blocked thread
>
>
> > Yet that may not help if I get into a situation where there’s a
> potential
> > deadlock that I may want to rollback by killing one of the deadlocked
> > threads. That synchronization object may not be mine, yet my thread is
> hung
> > on it, now what ?
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
> > Sent: Thursday, January 29, 2004 11:39 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Gracefully killing a blocked thread
> >
> >
> > Presumably you would have an “error” or “abort” synchronization object
> > that the thread is waiting on in addition to whatever other objects
> it’s
> > waiting on.
> >
> > Chuck
> >
> > ----- Original Message -----
> > From: “Moreira, Alberto”
> > To: “Windows System Software Devs Interest List”
> > Sent: Thursday, January 29, 2004 11:18 PM
> > Subject: RE: [ntdev] Gracefully killing a blocked thread
> >
> >
> > > So, if the reason for the blocking has crashed and we know that the
> > thread
> > > is never going to be unblocked, should it stay there forever like a
> > zombie ?
> > >
> > >
> > > Alberto.
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
> > Shatskih
> > > Sent: Thursday, January 29, 2004 11:09 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Gracefully killing a blocked thread
> > >
> > >
> > >
> > > No. The thread is blocked for a reason, and, if the reason did
> not
> > > occur, then it must stay waiting.
> > >
> > > Note that TerminateThread is a bad API (it causes the user stack
> > of the
> > > thread to go leak), practically never useful. Why ever terminating a
> > thread
> > > inside the alive process which continue to run?
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com mailto:xxxxx
> > > http://www.storagecraft.com http:
> > >
> > >
> > > ----- Original Message -----
> > > From: Deepu.L.R mailto:xxxxx
> > > To: Windows System Software Devs Interest
> > mailto:xxxxx List
> > >
> > > Sent: Thursday, January 29, 2004 1:47 PM
> > > Subject: [ntdev] Gracefully killing a blocked thread
> > >
> > > hi all,
> > >
> > > Is there any way to gracefully terminate (other than using
> > > TerminateThread) a blocked thread in Nt/2000/2003?
> > >
> > > regards
> > > Deepu.L.R
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > http:
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > mailto:xxxxx
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > xxxxx@compuware.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > >
> > >
> > > The contents of this e-mail are intended for the named addressee
> only.
> > It
> > > contains information that may be confidential. Unless you are the
> > named
> > > addressee or an authorized designee, you may not copy or use it, or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee only.
> It
> > contains information that may be confidential. Unless you are the
> named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@earthlink.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>

24

> I can hardly imagine the multi-threaded architecture which will be able to recover from the situation when one of its threads was killed by TerminateThread.

They exist. They require extensive resource tracking to implement, but they exist. And I’m talking about commercial mainframe OS, not a toy for the inside of a laser printer.

No, it is NOT easy to do. It may be impossible where there can be 3rd party kernel software, such as in NT, since all threads have to follow the rules. Which means that the rules must be known! (And yes, even in this case there are a very few instances where a reboot is the answer. But it will be a more complex case than a device driver mucking itself up, or a minor peripheral failing.)

Loren
----- Original Message -----
From: Maxim S. Shatskih
To: Windows System Software Devs Interest List
Sent: Thursday, January 29, 2004 12:27 PM
Subject: Re: [ntdev] Gracefully killing a blocked thread

The “reason for the blocking” is inside the same process - or inside the kernel.

If it is inside the same process - then kill the process and restart it (together with the address space data). At least the new process will be guaranteed to be operable.
If it is inside the kernel - then sorry, but you need to reboot.

I can hardly imagine the multi-threaded architecture which will be able to recover from the situation when one of its threads was killed by TerminateThread.

That is why the unhandled exception kills the whole process and not the thread.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: Moreira, Alberto
To: Windows System Software Devs Interest List
Sent: Thursday, January 29, 2004 7:18 PM
Subject: RE: [ntdev] Gracefully killing a blocked thread

So, if the reason for the blocking has crashed and we know that the thread is never going to be unblocked, should it stay there forever like a zombie ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Thursday, January 29, 2004 11:09 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Gracefully killing a blocked thread

No. The thread is blocked for a reason, and, if the reason did not occur, then it must stay waiting.

Note that TerminateThread is a bad API (it causes the user stack of the thread to go leak), practically never useful. Why ever terminating a thread inside the alive process which continue to run?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: Deepu.L.R
To: Windows System Software Devs Interest List
Sent: Thursday, January 29, 2004 1:47 PM
Subject: [ntdev] Gracefully killing a blocked thread

hi all,

Is there any way to gracefully terminate (other than using TerminateThread) a blocked thread in Nt/2000/2003?

regards
Deepu.L.R

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

25

Yup. Well, one could complain loudly to the author of the lower-level
driver. Or threaten to kill. I personally find the latter to be more
effective. =^)

Chuck

----- Original Message -----
From: “Loren Wilton”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 03, 2004 9:15 AM
Subject: Re: [ntdev] Gracefully killing a blocked thread

> Agreed, but how do you handle the case where your driver is blocked in
a
> lower-level driver and is never going to come back, because the lower
level
> driver or device is broke, and you didn’t have any control over what
it
> waited on?
>
> (Just to throw some petrol on the fire…)
>
> Loren
>
> ----- Original Message -----
> From: “Chuck Batson”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, January 29, 2004 9:51 AM
> Subject: Re: [ntdev] Gracefully killing a blocked thread
>
>
> > You should have a sync. object that is yours, a unique one per
thread
> > if necessary (i.e. if you want per-thread abortion control), that is
> > used to abort any and all waits in a thread. The point being that
your
> > thread should never be able to hang indefinitely on any particular
wait
> > (because you can exit any particular wait by signalling the
appropriate
> > abort sync. object), and give the thread a chance to clean up before
> > terminating.
> >
> > Chuck
> >
> > ----- Original Message -----
> > From: “Moreira, Alberto”
> > To: “Windows System Software Devs Interest List”

> > Sent: Friday, January 30, 2004 12:27 AM
> > Subject: RE: [ntdev] Gracefully killing a blocked thread
> >
> >
> > > Yet that may not help if I get into a situation where there’s a
> > potential
> > > deadlock that I may want to rollback by killing one of the
deadlocked
> > > threads. That synchronization object may not be mine, yet my
thread is
> > hung
> > > on it, now what ?
> > >
> > > Alberto.
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
> > > Sent: Thursday, January 29, 2004 11:39 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Gracefully killing a blocked thread
> > >
> > >
> > > Presumably you would have an “error” or “abort” synchronization
object
> > > that the thread is waiting on in addition to whatever other
objects
> > it’s
> > > waiting on.
> > >
> > > Chuck
> > >
> > > ----- Original Message -----
> > > From: “Moreira, Alberto”
> > > To: “Windows System Software Devs Interest List”

> > > Sent: Thursday, January 29, 2004 11:18 PM
> > > Subject: RE: [ntdev] Gracefully killing a blocked thread
> > >
> > >
> > > > So, if the reason for the blocking has crashed and we know that
the
> > > thread
> > > > is never going to be unblocked, should it stay there forever
like a
> > > zombie ?
> > > >
> > > >
> > > > Alberto.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
> > > Shatskih
> > > > Sent: Thursday, January 29, 2004 11:09 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: Re: [ntdev] Gracefully killing a blocked thread
> > > >
> > > >
> > > >
> > > > No. The thread is blocked for a reason, and, if the reason
did
> > not
> > > > occur, then it must stay waiting.
> > > >
> > > > Note that TerminateThread is a bad API (it causes the user
stack
> > > of the
> > > > thread to go leak), practically never useful. Why ever
terminating a
> > > thread
> > > > inside the alive process which continue to run?
> > > >
> > > > Maxim Shatskih, Windows DDK MVP
> > > > StorageCraft Corporation
> > > > xxxxx@storagecraft.com mailto:xxxxx
> > > > http://www.storagecraft.com http:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Deepu.L.R mailto:xxxxx
> > > > To: Windows System Software Devs Interest
> > > mailto:xxxxx List
> > > >
> > > > Sent: Thursday, January 29, 2004 1:47 PM
> > > > Subject: [ntdev] Gracefully killing a blocked thread
> > > >
> > > > hi all,
> > > >
> > > > Is there any way to gracefully terminate (other than using
> > > > TerminateThread) a blocked thread in Nt/2000/2003?
> > > >
> > > > regards
> > > > Deepu.L.R
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > > http:
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > > mailto:xxxxx
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> > > xxxxx@compuware.com
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > >
> > > >
> > > >
> > > > The contents of this e-mail are intended for the named addressee
> > only.
> > > It
> > > > contains information that may be confidential. Unless you are
the
> > > named
> > > > addressee or an authorized designee, you may not copy or use it,
or
> > > disclose
> > > > it to anyone else. If you received it in error please notify us
> > > immediately
> > > > and then destroy it.
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > xxxxx@compuware.com
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> > >
> > >
> > > The contents of this e-mail are intended for the named addressee
only.
> > It
> > > contains information that may be confidential. Unless you are the
> > named
> > > addressee or an authorized designee, you may not copy or use it,
or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@earthlink.net
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>