What's the proper way to terminate a thread?
Say I have an app that has 3 threads that need to be syncronized. When the user clicks a button, I need for the main thread to be able to terminate the other two. What's the cleanest way to do this if execution speed is a concern?

Let me clairify a bit. Thread 1 is the main app that services user input. Thread 2 will continuously read data from a file. Thread 3 will convert that data to another format. Now when the user selects a different file, say in a playlist, I would call
TerminateThread on the two file buffering threads and then start two new threads. Is this the proper way to go about things?
Will it leave memory leaks in the os?

Or what's the best way to syncronize between threads without getting invalid file handles, etc. What I really want to do is tell the thread not to execute any more calls. Just cleanup and terminate.
Posted on 2002-06-16 00:38:42 by grv575
TerminateThread doens't cause any memory leak as long as your resources allocated within the thread are deallocated before the thread gets terminated.

In your case, if your main thread calls TerminateThread to termiate the thread which reads data from file, it will most likely leave the file handle unclosed (memory leak).
Posted on 2002-06-16 01:01:05 by C.Z.
You can use some flag to tell the threads to stop their doings.
If the threads don't allocate any resources, TerminateThread shouldn't
cause leaks.
However, if you're going to stop the threads and immediately spawn
two news, it makes more sense to keep the threads... instead of
terminating them, signal that they should work on new filedata.
Posted on 2002-06-16 05:32:20 by f0dder
Originally posted by f0dder
it makes more sense to keep the threads... instead of
terminating them, signal that they should work on new filedata.


Good idea!:alright:
Posted on 2002-06-16 05:40:47 by C.Z.
I'm not allocating any resources in the thread. Just waiting for an event and copying memory -> memory. But it looks like the thread's stack or something isn't deallocated when I terminate it. At least the memory footprint of the program increases with each createthread/terminatethread pair.
Posted on 2002-06-16 22:13:14 by grv575

At least the memory footprint of the program increases with each createthread/terminatethread pair. I'm not allocating any resources in the thread. Just waiting for an event and copying memory -> memory. But it looks like the thread's stack or something isn't deallocated when I terminate it.


Memory for stack and heap is always freed in TerminateThread.
You still find there memory leaking? :confused: Maybe you could post some of your code?
Posted on 2002-06-16 23:33:58 by C.Z.
Might be that the deallocation/decommitting is done lazily.
Watch the app over time.
Also, you really ought to re-use threads, less strain on the system.
Posted on 2002-06-17 07:40:52 by f0dder
Yeah I guess it wasn't the thread that was leaking memory. Just wrote a small test app and terminatethread does free the memory allocated. Contrary to what msdn had to say about the subject:

"When this occurs, the target thread has no chance to execute any user-mode code and its initial stack is not deallocated"

Then again the test app just created and terminated threads in a loop. The thread procedures consisted of xor eax, eax/ret. Maybe a stack isn't created for each thread unless some actual memory is accessed.
Posted on 2002-06-18 01:04:52 by grv575

The thread procedures consisted of xor eax, eax/ret

The threads probably return before you have a chance to terminatethread them.
To do TerminateThread testing, do a "jmp $" in the threadproc.

I believe the initial thread stack by default have as much committed
as the main thread (ie, the value in the PE header), unless of course
you specify another stack value in the CreateThread call.
Posted on 2002-06-18 01:39:14 by f0dder
Yeah I did forget to put a loop in the threads.

Maybe MSDN is right after all about the stack not being freed.
Run this test app, open up Task Manager, and watch the memory usage grow...
Posted on 2002-06-18 02:11:38 by grv575
Here's another test. I wanted to test the theory that windows might
do "lazy cleanup" of the thread stacks, ie purge them when the
process (and system) was idle. Thus I implemented a "toggle"
button that toggles the creation of new threads. I also did some
critical section stuff to avoid the situation where the thread-spawning
thread is suspended before it can TerminateProcess the spawned
thread ("jmp $" gives 100% CPU usage (well, not really, but...),
and thus doesn't qualify as 'idle' :)).
Posted on 2002-06-18 02:59:16 by f0dder