Re: [BULK] Re: Exiting threads safely
- From: "Will Pearson" <will@xxxxxxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Sun, 30 Dec 2007 15:07:32 -0000
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:
