Re: Exiting threads safely

Hi Sean,

I think that using a process finding mechanism might result in a race 
condition.  The main thread for the application, and thus the application 
itself, might terminate before your process finding mechanism has had a chance 
to run.

Using multiple WaitForSingleObjects also has its problems.  A thread might nnot 
be waiting on the object that signals process shutdown.  If the other event 
isn't signalled to free the thread then the thread won't get an opportunity to 
wait on the event that does signal process shutdown, and the thread will be 
forceably terminated when the application terminates without processing the 
termination event.

If you want a clean termination of the thread then WaitForMultipleObjects will 
probably provide the best chance of getting it.  The way I've used 
WaitForMultipleObjects to accomplish this in the past is to have one of the 
events indicate that the thread should terminate.  I then use a while loop, 
just as you have done, and process the event ID, which is the value returned by 
WaitForMultipleObjects, using a switch statement.  If the event that signalled 
the thread indicates that the thread should terminate then the appropriate case 
in the switch statement sets the bool value used for the while loop to either 
true or false, depending on which one I've used to exit the while loop.  So, 
the code looks something like:

while (Run == TRUE) {
Event = WaitForMultipleObjects(2, hFoo, FALSE, INFINITE);

switch (Event) {
case 0: Run = FALSE;
break;
case 1: // do something
break;
} // switch
} // while

In the above example I've placed the event that signals the termination of the 
thread at array index 0 of the array containing the wait handles.  
WaitForMultipleObjects will return the lowest numbered event as the return 
value if multiple events are signalled at the same time.  Placing the 
termination event at array index 0 ensures that the termination event will 
always be returned if it is signalled and that the loop will exit when it is 
signalled.

Using WaitForMultipleObjects doesn't completely eliminate the possibility that 
the process can terminate without your thread receiving the termination signal 
but it does reduce the possibility that this could happen compared to using two 
WaitForSingleObject calls.  If your thread is doing some work and not waiting 
on an event then there is still the possibility that the application's main 
thread could exit before your thread processes the termination signal.  If you 
want your thread to cleanly terminate before the process terminates because you 
need to do some clean up or something then you need to serialise the execution. 
 The way I usually go about this is to have the application's main thread wait 
on an event until the other thread has done its clean up or whatever work it 
has to do.  Just before the thread exits, usually just before the end of the 
function that I passed in as the starting function to a call to _beginthreadex, 
I set the event that the application's main thread is waiting on to signelled.  
This serialises execution and ensures that the clean up code or whatever work I 
want done will be done before the process terminates.

Will
  ----- Original Message ----- 
  From: Sean Farrow 
  To: programmingblind@xxxxxxxxxxxxx 
  Sent: Sunday, December 30, 2007 11:49 AM
  Subject: Exiting threads safely


  Hi list: 
  I am in a situation wher i am creating threads in a com server. The threads 
use WaitForSingleObject to process cross process communication. I need to exit 
these two created threads when --and only when an application exits. is the 
safest way to do thi using a process finding mechanism (I aleady have this in 
place anyway) or using a second event. If the latter, can I use this in a while 
lop like the following:
  while(WaitForSingleObject(hevent, infinite) !=0)
  {
  code if the thread isn't to exit--i.e wait on the first event.
  } 
  exit the thread using an ExitThread call.
  Any help apreciated.
  Sean.

Other related posts: