Question

I am implementing a protocol library. Here a simplified description.

The main thread within the main function will always check, whether some data is available on the the networkstream (within a tcpclient). Let us say response is the received message and thread is a running thread.

thread = new Thread(new ThreadStart(function));
thread.IsBackground = true;
thread.Start();

while(true){

response = receiveMessage();

if (response != null)
     {                
      thread.Suspend();
      //I am searching for an alternative for the line above and not thread.Abort().

      thread2 = new Thread(new ThreadStart(function2));
      thread2.IsBackground = true;
      thread2.Start();         
     }
}

So far so good, there are actually more messages to come within the while loop and there is also a statemachine for handling different sort of incoming messages, but this should be enough.
(There are also more than just the functions “function” and “function2”).

So anyways how the functions look inside is not clear in this application, since the protocol is hidden from the programmer and meant to be a library. This means the protocol will start some programmer-defined functions as a thread depending on at what state in the protocol the program is.

So if then a special response is received (e.g. a callAnotherFunction message), I want to terminate
a thread (here named “thread”) abruptly, lets say within 100 ms. But I do not know whether it executes within a loop or without and how much processing is needed until it terminates.

How to stop these threads without deprecated Suspend or Exceptionthrowing Abort function?
(Note that I cannot force the programmer of the functions to catch the ThreadAbortException.)

Or do I need a different programme architecture?
(Btw I have decided to put the loop within receiveMessage for polling the network stream into the main function, since anytime a message can appear).

Answer 1

Starting a thread without having a reliable way to terminate it is a bad practice. Suspend/Abort are one of those unreliable ways to terminate a thread because you may terminate a thread in a state that corrupts your entire program and you have no way to avoid it from happening.

You can see how to kill a thread safely here: Killing a .NET thread

If the “user” is giving you a method to run in a thread, then the user should also give you a method to stop the code from running. Think of it as a contract: you promise the user that you will call the stop method and they promise that the stop method will actually stop the thread. If your user violates that contract then they will be responsible for the issues that arise, which is good because you don’t want to be responsible for your user’s errors :).

Note that I cannot force the programmer of the functions to catch the ThreadAbortException.

Since Suspend/Abort are bad practice, the programmer doesn’t need to catch the ThreadAbortException, however they should catch the ThreadInterruptedException as part of their “contract.”

Remember that there are two situations you need to worry about:

1. The thread is executing some code.
2. The thread is in a blocking state.

In the case that the thread is executing some code, all you can do is notify the thread that it can exit and wait until it processes the notification. You may also skip the waiting and assume that you’ve leaked a resource, in which case it’s the user’s fault again because they didn’t design their stop method to terminate their thread in a timely fashion.

In the case where the thread is in a blocking state and it’s not blocking on a notification construct (i.e. semaphore, manual reset event, etc) then you should call Thread.Interrupt() to get it out of the blocking state- the user must handle the ThreadInterruptedException.