Remaining treads at application exit?
Hello! What is a good way of managing the closeure of remaining treads when the application is about to terminate? Currently i have a counter which is incremented and decremented at beginning and end of the tread endry function. But this has some flaws, for instance, the tread could be lockedup in neverending loops polling non-blocking functions. This could be solved by checking for application termination in all such loops but i dunno, feels like bugs could sneak in here.. And you could not use any blocking functions at all with this approche, since then there is a chanse it will never return or return after a long timeout. I read that TerminateTread isn't very safe to use, so i would like to avoid that. In the main tread on exit i poll to see if any treads are still running, and only after there are no more treads it exits. All input is greatly appreciated, thanks in advance!
Shields up! Rrrrred alert!
Just check for a boolean flag and quit nicely. If the worker thread is blocked on a socket operation, then simply close the socket from the main thread to force an error in the worker thread; the worker thread can first check for the boolean before analyzing the error. After closing all sockets, the main threads waits for all the worker threads to exit.
If worker threads have significant computation to perform per loop, then you should divide the computations into blocks so that termination is under control. Better still, implement a task tree that a thread pool can pull tasks from; tasks could either be complete computations, or split a task into more tasks. If those sub-tasks are data-independent from one another, then you minimize the amount of critical locks each thread needs to do in order to perform the tasks' computation.
> TerminateTread
That's a no-no for sure. There is a way to toast the entire process in one shot in both Unix and Win32, but that may induce incompleteness in the file system (file corruption, half-written files, temporary files or named pipes that need be deleted, etc) that your application would have to deal with when it is restarted.
Hope this helps.
-cb
If worker threads have significant computation to perform per loop, then you should divide the computations into blocks so that termination is under control. Better still, implement a task tree that a thread pool can pull tasks from; tasks could either be complete computations, or split a task into more tasks. If those sub-tasks are data-independent from one another, then you minimize the amount of critical locks each thread needs to do in order to perform the tasks' computation.
> TerminateTread
That's a no-no for sure. There is a way to toast the entire process in one shot in both Unix and Win32, but that may induce incompleteness in the file system (file corruption, half-written files, temporary files or named pipes that need be deleted, etc) that your application would have to deal with when it is restarted.
Hope this helps.
-cb
Thanks for your reply.
Thats a good idea, to close all sockets from the main tread. But there is still the problem with the main tread knowing if there are any threads still running when it wants to shutdown. I guess i could just wait a few millisecs after closing all sockets, but there must be a better solution.
Thats a good idea, to close all sockets from the main tread. But there is still the problem with the main tread knowing if there are any threads still running when it wants to shutdown. I guess i could just wait a few millisecs after closing all sockets, but there must be a better solution.
Shields up! Rrrrred alert!
Look up WaitForSingleObject()
I think you'll find it does what you need.
-=[ Megahertz ]=-
I think you'll find it does what you need.
-=[ Megahertz ]=-
-=[Megahertz]=-
The graceful way -
When you (successfully) create a thread do an InterlockedIncrement on a shared counter to keep track of the number of threads, you should also ResetEvent on an event that says whether or not there are any worker threads. When a thread exits it InterlockedDecrements the counter. If the result is zero then it sets the "no worker threads" event before exiting. To shutdown your app gracefully signal all the threads to exit and WaitForSingleObject until the "no worker threads" event gets set.
The other way -
All that work often doesn't really accomplish much if you're shutting down your app anyway. Just call exit and the OS will cleanup the threads for you.
When you (successfully) create a thread do an InterlockedIncrement on a shared counter to keep track of the number of threads, you should also ResetEvent on an event that says whether or not there are any worker threads. When a thread exits it InterlockedDecrements the counter. If the result is zero then it sets the "no worker threads" event before exiting. To shutdown your app gracefully signal all the threads to exit and WaitForSingleObject until the "no worker threads" event gets set.
The other way -
All that work often doesn't really accomplish much if you're shutting down your app anyway. Just call exit and the OS will cleanup the threads for you.
-Mike
hm I guess I should also mention that instead of the counter and event business you keep track of the handles of all the threads you create and wait on them instead.
The advantages are that's a bit easier to get the race conditions straightened out and the disadvantes are that it's more info you need to keep around.
The advantages are that's a bit easier to get the race conditions straightened out and the disadvantes are that it's more info you need to keep around.
-Mike
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement