Re: [BULK] Re: Exiting threads safely

Hi Sean,

Using CreateThread and EndThread can result in memory leaks if you then go on 
to call some of the CRT functions.  This is because some of the CRT functions 
use global variables, such as errno, or allocate static buffers, and these have 
one copy per thread to prevent race conditions.  If you create a thread using 
CreateThread and terminate it using EnThread then these per thread global 
variables and static buffers won't be freed by the CRT when the thread exits.  
So, to avoid a memory leak you need to use the CRT functions to create and end 
threads such as _beginthread and _endthread or _beginthreadex and _endthreadex. 
 It's also worth noting that you don't need to manually end a thread by calling 
something like _endthread.  The thread will terminate by itself when its start 
function exits.

WaitForMultipleObjects returns a DWORD value that represents the event that was 
signalled.  Under some circumstances it can return other values to indicate 
other things, and the MSDN Library entry for WaitForMultipleObjects explains 
what these are.

Will
  ----- Original Message ----- 
  From: Sean Farrow 
  To: programmingblind@xxxxxxxxxxxxx 
  Sent: Sunday, December 30, 2007 2:24 PM
  Subject: RE: [BULK] Re: Exiting threads safely



  Hi Will: 
  What are the benefits of using BeginTgheadEx over the standard thread proc, 
wich is what I am usin at the moment? 
  And What does WaitForMultipleObjects return?
  Sean.



------------------------------------------------------------------------------
  From: programmingblind-bounce@xxxxxxxxxxxxx 
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
  Sent: 30 December 2007 14:16
  To: programmingblind@xxxxxxxxxxxxx
  Subject: [BULK] Re: Exiting threads safely
  Importance: Low


  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: