Exiting another thread

[MainBrain]

Hello,

i have two running threads A and B. B listens for events on the network.
On a specified event B has to stop the execution of A.
Currently i am using:
BOOL WINAPI TerminateThread(HANDLE hThread,DWORD dwExitCode);
to achieve this.
Problem is that the object destructor's in A are not invoked.

Microsoft refers to:
VOID WINAPI ExitThread(DWORD dwExitCode);
for a safer way of exiting a thread. But the problem here is, that a thread can only terminate itself and not another thread.

Thank you in advance.

Greetings,
MainBrain

[MrViggy]

Use some kind of messaging. As thread A is working, periodically check some variable. If it's set to some value, just exit the thread function in A. For example:
// In thread A...
void ThreadFunc(void *)
{
while (!someStopVar)
{
// DO stuff...
}
}

// In thread B...
void ThreadBFunc(void *)
{
if (shouldWeStopA)
someStopVar = true;
...
}
Something like that...

Viggy

[Arjay]

Another way besides what MrViggy posted is to use an event to signal a thread to exit.


// In thread A...
void ThreadFunc(void *)
{

while ( WAIT_OBJECT_0
!= WaitForSingleObject( hShutdownEvent, 0 ) )
{
// DO stuff...
}
}

// In thread B...
void ThreadBFunc(void *)
{
if (shouldWeStopA)
{
// Tell ThreadA to exit
SetEvent( hShutdownEvent );
}
// Wait for thread a to exit
WaitForSingleObject( hThreadA, some timeout );

// Check if thread is still alive
DWORD dwExitCode = 0;
if( STILL_ACTIVE == GetThreadExitCode( hThreadA, &dwExitCode ) )
{
// Time to get rough
TerminateThread( hThreadA );
}

...
}

[KentBill]

To stop a thread by TerminateThread is not a best way, because if any resource is alloc by the thread, and the B send a message to stop A, the resource what alloc by thread A may be can not recycled.

[MainBrain]

Sorry, there was an important thing i haven't told you.
The threads are NOT cyclic/periodic, so the solutions you have talked about won't help me.

"A" does its job and finishes within a given time. "B" monitors the environment for problems caused by the actions of "A". The biggest problem is, that the Objects allocated by "A", HAVE to be destroyed properly.

Example:
thread_function(...)
{
...
// here comes a very long error-prone computation
...
// End of thread. No cycle. Computation is done only once.
}

[MrViggy]

Well, if "B" is monitoring "A", then when "A" is done, just send a message to "B", and let the thread function exit. A thread ends when the function used in the thread just exits. No need to call anything.

If you want "B" to cancel "A", then just periodically check the flag you setup:
// Thread "A" func...
void someThreadFunc(void *)
{
// Do some stuff...
if (shouldWeStopA)
return;

// Do more stuff...
if (shouldWeStopA)
return;
}
If you can't break up your work like this, then you're pretty much out of luck.

Viggy

[Arjay]

To stop a thread by TerminateThread is not a best way, because if any resource is alloc by the thread, and the B send a message to stop A, the resource what alloc by thread A may be can not recycled.In the code I presented, TerminateThread is used as a last resort which beats not being able to close the app. What the snipped didn't show was that the code needs to inform the caller that the thread needed to be terminated, so the app could inform the user, provide other cleanup, etc.

[MainBrain]

I appreciate your answers. I think i have to live with periodic checking...

Just out of curiosity: Can anybody tell me why it is not possible to force a thread to exit properly? Why is it not possible to throw an Exception in a foreign thread? What is the technical reasoning behind this?

[Arjay]

I appreciate your answers. I think i have to live with periodic checking...

Can anybody tell me why it is not possible to force a thread to exit properly? Why is it not possible to throw an Exception in a foreign thread?At present, you can externally kill a thread, but the issue simply boils down to the ability to cleanup resources. A thread externally killed with TerminateThread, just stops dead so no destructors get called nor is any other cleanup performed. To fix this problem, the OS designers would have to introduce some sort of 'thread destructor' concept where a routine is guaranteed to always run no matter how the thread is stopped. Once that feature has been added, then it would be somewhat trivial to add external management capabilities to stop a thread.
As it stands, your only options are to externally trigger the thread to exit as mentioned in earlier replys.

[MainBrain]

Yes, but what about exceptions? Why not introduce a new exception like "ThreadTerminationException" and throw it from within the target thread. Why is it a problem for the OS developers to throw an exception in another thread?

I'm just curious...

[Arjay]

I think I see what you are asking for. Say thread A starts thread B. I believe you would like thread B to throw an exception (e.g. ThreadTerminationException) that thread A can catch. Is that right?

If so, this might be difficult for the OS to track considering the fact that thread A and thread B can run on different processors. The OS would have to keep track of which thread throws this type of exception, and determine if there are any catch blocks around to catch the exception on threads running on other processors. Not impossible, but it might add too much overhead to be practical.