Thread: Suspending best practice
-
I am just curious as to the best practice for suspending a thread. We have a thread that every once in awhile is required to do something. I am currently using SuspendThread on the CWinThread object. When the thread needs to do work, I Resume the thread. That seems to work well and does not eat up any CPU. But I am just wondering if a better way is to WaitForSingleObject and use an Event to resume the thread. Using SuspendThread works and is certainly easy to implement, but am just curious which way may provide a better design. Thanks for the insight. Note: We were originally ending the thread when it was done with its job, but ran into some other problems. This thread calls into something else which uses OpenMP for multi-threading. When our C++ client thread ended, the OMP threads did not seem to get removed so we kept accumulating OMP threads until we eventually get an error saying too many OMP threads.
-
I am just curious as to the best practice for suspending a thread. We have a thread that every once in awhile is required to do something. I am currently using SuspendThread on the CWinThread object. When the thread needs to do work, I Resume the thread. That seems to work well and does not eat up any CPU. But I am just wondering if a better way is to WaitForSingleObject and use an Event to resume the thread. Using SuspendThread works and is certainly easy to implement, but am just curious which way may provide a better design. Thanks for the insight. Note: We were originally ending the thread when it was done with its job, but ran into some other problems. This thread calls into something else which uses OpenMP for multi-threading. When our C++ client thread ended, the OMP threads did not seem to get removed so we kept accumulating OMP threads until we eventually get an error saying too many OMP threads.
StevenS_Dev wrote:
But I am just wondering if a better way is to WaitForSingleObject and use an Event to resume the thread.
Yes, that's probably a much better approach because you are in full control about what is happening. When you call SuspendThread, you have absolutely no idea where the thread will be stopped. Perhaps right in the middle of something important. With the other approach, you fully complete the task, then swith in a 'wait state' (waiting for the event to be signaled).
Cédric Moonen Software developer
Charting control [v1.4] OpenGL game tutorial in C++ -
I am just curious as to the best practice for suspending a thread. We have a thread that every once in awhile is required to do something. I am currently using SuspendThread on the CWinThread object. When the thread needs to do work, I Resume the thread. That seems to work well and does not eat up any CPU. But I am just wondering if a better way is to WaitForSingleObject and use an Event to resume the thread. Using SuspendThread works and is certainly easy to implement, but am just curious which way may provide a better design. Thanks for the insight. Note: We were originally ending the thread when it was done with its job, but ran into some other problems. This thread calls into something else which uses OpenMP for multi-threading. When our C++ client thread ended, the OMP threads did not seem to get removed so we kept accumulating OMP threads until we eventually get an error saying too many OMP threads.
StevenS_Dev wrote:
I am just curious as to the best practice for suspending a thread.
Best practice for using SuspendThread is to never use it. http://www.flounder.com/workerthreads.htm#Pausing%20a%20Thread[^] http://blogs.msdn.com/oldnewthing/archive/2003/12/09/55988.aspx[^] http://blog.kalmbachnet.de/?postid=6[^] You should design your CWinThread class to utilize thread messages and/or synchronization objects.[^] Best Wishes, -David Delaune
-
I am just curious as to the best practice for suspending a thread. We have a thread that every once in awhile is required to do something. I am currently using SuspendThread on the CWinThread object. When the thread needs to do work, I Resume the thread. That seems to work well and does not eat up any CPU. But I am just wondering if a better way is to WaitForSingleObject and use an Event to resume the thread. Using SuspendThread works and is certainly easy to implement, but am just curious which way may provide a better design. Thanks for the insight. Note: We were originally ending the thread when it was done with its job, but ran into some other problems. This thread calls into something else which uses OpenMP for multi-threading. When our C++ client thread ended, the OMP threads did not seem to get removed so we kept accumulating OMP threads until we eventually get an error saying too many OMP threads.
Thanks for the answers. That is what I figured, but wanted real data to support it.
-
I am just curious as to the best practice for suspending a thread. We have a thread that every once in awhile is required to do something. I am currently using SuspendThread on the CWinThread object. When the thread needs to do work, I Resume the thread. That seems to work well and does not eat up any CPU. But I am just wondering if a better way is to WaitForSingleObject and use an Event to resume the thread. Using SuspendThread works and is certainly easy to implement, but am just curious which way may provide a better design. Thanks for the insight. Note: We were originally ending the thread when it was done with its job, but ran into some other problems. This thread calls into something else which uses OpenMP for multi-threading. When our C++ client thread ended, the OMP threads did not seem to get removed so we kept accumulating OMP threads until we eventually get an error saying too many OMP threads.
Don't use SuspendThread[^]. You're been lucky so far but I wouldn't count on that continuing. See this article on why you should never suspend a thread[^]. The documentation for SuspendThread[^] also points out the dangers of using it as you are:
This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization. Calling SuspendThread on a thread that owns a synchronization object, such as a mutex or critical section, can lead to a deadlock if the calling thread tries to obtain a synchronization object owned by a suspended thread. To avoid this situation, a thread within an application that is not a debugger should signal the other thread to suspend itself. The target thread must be designed to watch for this signal and respond appropriately.