2

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).

Sam
  • 7,252
  • 16
  • 46
  • 65
Vladimir S.
  • 450
  • 2
  • 10
  • 23
  • Are we missing something? Change while(true), to while(keepLooping) and then inside the loop if you detect you don't set it to false, thread finishes gracefully???? – Tony Hopkinson Apr 03 '12 at 17:01

4 Answers4

4

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.

Community
  • 1
  • 1
Kiril
  • 39,672
  • 31
  • 167
  • 226
1

Suspend is really evil especially in a way you are trying to use it - to stop thread execution forever. It will leave all locks that thread had and also will not release resources.

Thread Abort is slightly better since it will at least try to terminate thread cleaner and locks will have chance to be released.

To properly do that you really need your thread's code to cooperate in termination. Events, semaphores or even simple bool value checked by the thread may be enough.

It may be better to re-architect your solution to have queue of messages and process them on separate thread. Special message may simply empty the queue.

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
1

You need some sort of cancellation protocol between your application and wherever function comes from. Then you can share some sort of cancellation token between function and your message loop. If message loop recognizes that function needs to be stopped you signal that by setting that token which must be tested by function on proper occasions. The simplest way would be to share a condition variable which can be atomically set from within your message loop and atomically read from function.

I'd however consider using the proper Asynchronous IO patterns combined with Tasks provided by the .NET framework out-of-the box along with proper cancellation mechanisms.

Paul Michalik
  • 4,331
  • 16
  • 18
  • I have just checked asynchornous I/O and it seems, that it only makes sense, if I know which message is expected and if it is sure no other message can arrive. For my case I need to monitor and decode incoming messages all the time and react on them by killing a thread and starting a new function depending on which message is received. This means, even during a callback a message could appear. Or do I see something wrong here? – Vladimir S. Apr 04 '12 at 09:12
  • With Async IO you "register" for incoming messages at some endpoint. Until no message arrive you do not consume CPU-time. On new message your registered client will be scheduled and gets the opportunity to process the message. In your role as a sender it works exactly the opposite way. The idea is that in sum much fewer resources are required to serve the same amount of request - if the proper infrastructure exists (e.g. an intelligent scheduler, asynchronous IO capabilities, etc.), of course. – Paul Michalik Apr 04 '12 at 10:49
1

So function refers to code which you have little control over? This is pretty typical of 3rd party libraries. Most of the time they do not have builtin abilities to gracefully terminate long running operations. Since you have no idea how these functions are implemented you have very few options. In fact, your only guaranteed safe option is to spin these operations up in their own process and communicate with them via WCF. That way if you need to terminate the operation abruptly you would just kill the process. Killing another process will not corrupt the state of the current process like what would happen if you called Thread.Abort on thread within the current process.

Brian Gideon
  • 47,849
  • 13
  • 107
  • 150