Correct way of checking if threads are done? - c++

I'm using multithreading in my application with _beginthread and right now to wait until all threads are done I have global bools that get set to true as each thread completes so I'm in a while loop until then. There must be a cleaner way of doing this?
Thanks

You can use WaitForMultipleObjects to wait for the threads to finish in primary thread.

What you want to have a look at is thread synchronization techniques - luckily there is quite a bit of information on MSDN which can probably help you out. It's likely you'll want to use Events and WaitHandles here's the main stuff on MSDN: http://msdn.microsoft.com/en-us/library/ms681924%28v=VS.85%29.aspx there are a number of examples.
There's also some info on synchronization in MFC (which may or may not prove helpful, added for reference purposes): http://msdn.microsoft.com/en-us/library/975t8ks0%28VS.71%29.aspx
I've done a bit of searching, but I've had a hard time trying to track down some helpful info for you which doesn't use the MFC implementation. There's a good tutorial here ( http://www.informit.com/library/content.aspx?b=Visual_C_PlusPlus&seqNum=149 ) but, again, using MFC. You could take a look at the MFC implementation of mutexes though as a start.
So, you'd need to get familiar with synchronization functions and structures - all covered here on MSDN: http://msdn.microsoft.com/en-us/library/ms686679%28v=VS.85%29.aspx

Use _beginthreadex instead. Both _beginthread and _beginthreadex return a thread handle, but the thread started with _beginthread automatically closes its handle when it finishes, so using it for synchronization is not reliable.
Thread handle can be used with one of the synchronization functions of Win32, such as WaitForSingleObject or WaitForMultipleObjects.
When done, handles returned by _beginthreadex must be closed with CloseHandle().

The usual method is to keep all of the thread handles and then wait on each handle. When the handle is signaled, the thread has finished so it is removed from the set of threads. I use std::set<HANDLE> to keep track of the thread handles. There are two different methods for waiting on multiple objects in Windows:
Iterate over the set and call WaitForSingleObject with a timeout on each one
Convert the set into an array or vector and call WaitForMultipleObjects
The first sounds inefficient, but it is actually the most direct and least error prone of the two. If you need to wait for all of the threads, then use the following loop:
std::set<HANDLE> thread_handles; // contains the handle of each worker thread
while (!thread_handles.empty()) {
std::set<HANDLE> threads_left;
for (std::set<HANDLE>::iterator cur_thread=thread_handles.begin(),
last=thread_handles.end();
cur_thread != last; ++cur_thread)
{
DWORD rc = ::WaitForSingleObject(*cur_thread, some_timeout);
if (rc == WAIT_OBJECT_0) {
::CloseHandle(*cur_thread); // necessary with _beginthreadex
} else if (rc == WAIT_TIMEOUT) {
threads_left.add(cur_thread); // wait again
} else {
// this shouldn't happen... try to close the handle and hope
// for the best!
::CloseHandle(*cur_thread); // necessary with _beginthreadex
}
}
std::swap(threads_left, thread_handles);
}
Using WaitForMultipleObjects to wait for the threads to finish is a bit more difficult than it sounds. The following will wait for all of the threads; however, it only waits for WAIT_MAXIMUM_OBJECTS threads at a time. Another options is to loop over each page of threads. I'll leave that exercise to the reader ;)
DWORD large_timeout = (5 * 60 * 1000); // five minutes
std::set<HANDLE> thread_handles; // contains the handle of each worker thread
std::vector<HANDLE> ary; // WaitForMultipleObjects wants an array...
while (!thread_handles.empty()) {
ary.assign(thread_handles.begin(), thread_handles.end());
DWORD rc = ::WaitForMultipleObjects(std::min(ary.size(), WAIT_MAXIMUM_OBJECTS),
&ary[0], FALSE, large_timeout);
if (rc == WAIT_FAILED) {
// handle a failure case... this is usually something pretty bad
break;
} else if (rc == WAIT_TIMEOUT) {
// no thread exited in five minutes... this can be tricky since one of
// the threads beyond the first WAIT_MAXIMUM_OBJECTS may have terminated
} else {
long idx = (rc - WAIT_OBJECT_0);
if (idx > 0 && idx < ary.size()) {
// the object at `idx` was signaled, this means that the
// thread has terminated.
thread_handles.erase(ary[idx]);
::CloseHandle(ary[idx]); // necessary with _beginthreadex
}
}
}
This isn't exactly pretty but it should work. If you trust that all of your threads will exit and don't mind waiting for them, then you can use WaitForMultipleObjects(ary.size(), &ary[0], TRUE, INFINITE). This usually isn't very safe though since a runaway thread will cause your application to block indefinitely and it will only work if ary.size() is less than MAXIMUM_WAIT_OBJECTS.
Of course the other option is to find a thread pool implementation and use it instead. Writing threading code is not really a lot of fun especially once you have to support it in the wild. Consider using something like boost::thread_group instead.

You can use boost::thread objects. Call join on the object and it will wait for the thread to finish.

Windows provides events for one thread to notify another. Out of the box Visual C++ provides support for events only inside MFC. For a portable, non-MFC version, check the thread management classes of the Boost library. They make launching and waiting for threads a lot easier, although they don't provide direct access to all of Windows API's functionality.

Related

ResumeThread sometimes doesn't wake threads

I have two functions in my C++: one to suspend, one to resume threads.
In some situations I need to stop all thread but current and it's ok, but when I must resume the threads, sometimes it doesn't work and I don't no why.
See the method:
void CDatabaseMonitor::ResumeAllThreads()
{
DWORD dwCurProc = GetCurrentProcessId();
HANDLE hCurProc = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
if (hCurProc != INVALID_HANDLE_VALUE)
{
THREADENTRY32 te = {0};
te.dwSize = sizeof(te);
if (Thread32First(hCurProc, &te))
{
do
{
if (te.dwSize >= FIELD_OFFSET(THREADENTRY32, th32OwnerProcessID) + sizeof(te.th32OwnerProcessID))
{
if (te.th32ThreadID != m_currentThreadId && te.th32OwnerProcessID == dwCurProc)
{
HANDLE thread = ::OpenThread(THREAD_ALL_ACCESS, FALSE, te.th32ThreadID);
if (thread != NULL)
{
ResumeThread(thread);
CloseHandle(thread);
}
}
}
te.dwSize = sizeof(te);
}
while (Thread32Next(hCurProc, &te));
}
CloseHandle(hCurProc);
}
}
Is there something worng with the code above?
Is there any way to force a thread to wake?
Thanks in advance.
You can't use SuspendThread/ResumeThread this way. As the docs say:
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.
The main problem is this -- there is basically nothing you can do while the thread is suspended. If the thread was holding a lock you require, you will deadlock waiting for it to release it. And you have no way to know what locks that thread might have because threads can be hijacked at arbitrary points to do arbitrary work by a number of mechanisms used by libraries.
You will never get this to work, and whatever problem you're trying to solve by suspending threads you should instead solve some other, sensible way.
The canonical answer to the question, "How do I safely suspend/resume a thread from another thread in the same process?" is "With that thread's cooperation, use whatever mechanism that thread supports. Without that thread's cooperation, it cannot be done safely."
Any time you feel like you need to "reach in" from the outside to make a thread do the right thing, you should step back and rethink your design. The thread should already be coded to do what, and only what, you want it to do. If the thread needs to suspend, it should be coded to suspend itself. If you have to reach in to make it do what you want or not do what you don't want, you coded it wrong in the first place and should fix it. All the threads in a process must cooperate.

C++: How to call a synchronous library call asynchronously?

I am working with a library that has a blocking call that never times out if it does not succeed. I would like to be able to handle this error condition more gracefully. I know there must be a way to wrap the call in a worker thread (or some other type of delegate object), wait x amount of seconds, and then throw an exception if x amount of seconds have passed. I only need to do this for one function in the library. How do I go about implementing this? I see similar examples all over the net but none that are doing exactly what I'm trying to do. Thanks!
My answer is "do not attempt to do this".
Sure, you can probably find some hack that will appear to work in your particular case. But the race conditions here are very hard to fix.
The obvious approach is to have thread A make the blocking call, then set up thread B to kill A if a timeout expires.
But... What if the timeout expires at the same time A is returning from the blocking call? Specifically, what if B thinks it is time to kill A, then your OS scheduler decides to run A for a while, then your OS decides to run the B code that kills A?
Bottom line: You wind up killing A at some indeterminate point in its execution. (For example, maybe it just deducted $500 from the savings account but has not yet added $500 to the checking account. The possibilities are endless...)
OK, so you can have thread A exist for the sole purpose of running the library call, and then signal a condition or whatever when it finishes. At least it is possible to make this work in principle. But even then, what if the library itself has some internal state that gets left in an inconsistent state should A get killed at an inopportune moment?
There are good reasons asynchronous thread cancellation was omitted from the C++11 standard. Just say no. Fix the library routine. Whatever that costs, it is almost certainly cheaper in the long run than what you are attempting.
Using C++11 then launching a thread explicitly for that call could look like:
// API
T call(int param);
// asynchronous call with 42 as parameter
auto future = std::async(std::launch::async, call, 42);
// let's wait for 40 ms
auto constexpr duration = std::chrono::milliseconds(40);
if(future.wait_for(duration) == std::future_status::timeout) {
// We waited for 40ms and had a timeout, now what?
} else {
// Okay, result is available through future.get()
// if call(42) threw an exception then future.get() will
// rethrow that exception so it's worth doing even if T is void
future.get();
}
As you can see in case of a timeout you have a big problem as you're stuck with a blocked thread forever. This is arguably not a fault of the C++11 std::future: a fair number of thread abstractions will provide at best cooperative cancellation, and that would still not be enough to save you.
If you're not using C++11 then Boost.Thread has a very similar interface with boost::unique_future (where wait_for is instead timed_wait, and returns bool), although it doesn't have something akin to std::async so you have to do some of the busywork yourself (with e.g. boost::packaged_task + boost::thread). Details available in the documentation.
Obviously the thread within which the blocking call is made cannot kill itself - it will be blocked.
One approach would be to launch a thread A that makes the blocking call, then launch another thread B that sleeps for the timeout then kills thread A. A mutex protected shared flag can indicate whether the operation succeeded, based on which an exception can be thrown or not.
A second approach (very similar) would be to launch a thread A, which in turn launches thread B, sleeps for the timeout, then kills thread B.
The specifics of your preferred threading library (such as which threads are allowed to kill each other) and the nature of the blocking function will impact exactly how you go about this.
On Windows, you will want to do something like this:
//your main thread
DWORD threadID;
HANDLE h = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&ThreadProc, 0, 0, &threadID);
DWORD ret = 0xFFFFFF;
for (int i = 0; i < /*some timeout*/; i++) {
ret = WaitForSingleObject(h, 100);
if (ret == WAIT_OBJECT_0) break;
}
if (ret != WAIT_OBJECT_0) {
DWORD exitCode;
TerminateThread(h, &exitCode); // you will want to stop the thread as it isn't exiting.
/*throw*/;
}
And
//Thread Routine
DWORD ThreadProc (LPVOID threadParam) {
//call your function here
return 0;
}
The idea here is to spin up a thread to do the work you want. You can then wait on that thread in
100 ms increments (or whatever you want). If it doesn't end within a certain time period, you can throw an exception.
There are some problems. First, does the library hold any internal state that will be left unuseable by a failed library call? If so, you are stuft because calls following the failed call that blocked will also fail or, worse, generate erroneous results without any exception or other notification.
If the library is safe, then you could indeed try to thread off the call and wait on some event with a timeout. It's now that you need to handle the concerns of #Nemo - you need to take care over how you handle the return of results. How exactly you do this depends on, well, how you intend to return results from the thread that calls the library. Typically, both threads would enter a critical section to safely arbitrate between the lib thread returning results and the timeout thread instructing the lib thread to never return anything, (eg. by setting a flag in it), and just exit if the lib call ever returns.
Orphaning the lib. thread is such a way will result in a thread leak if the lib call never returns. Whether you can absorb such leaks, or safely resort to eventual forced termination of the orphaned threads, is between you and your app :)

C++ pthreads multi-tasking [windows]

For a solution to an earlier problem, I was kindly pointed to multi-threading (via pthreads).
The original problem is thus:
I have two functions, one of which is the main body, which is real-time; the other is a continually running function that blocks. The real-time, when attempting to run the blocking function, obvious blocks, making it unresponsive to the user which is unacceptable as a real-time process.
The original aim was to make the blocking function independent of the real-time solution (or at least, pseudo-independent), which I attempted with pthreads.
Here's a simplified version of the code:
void * RenderImages(void * Data)
{
while(1); //Simulating a permanently blocking process
return NULL;
}
int main(int ArgC, char *ArgVar[])
{
pthread_t threads[PTHREAD_NUMBER];
void *Ptr = NULL;
int I = 0;
I = pthread_create(&threads[0], NULL, RenderImages, Ptr);
if(I != 0)
{
printf("pthread_create Error!\n");
return -1;
}
I = pthread_join(threads[0],NULL);
//Doesn't reach here as pthread_join is blocking
printf("Testing!\n");
return 0;
}
The code above, however, blocks on calling pthread_join (which makes pthread nothing more than an unnecessarily complicated way of calling the function directly - which defeats the point).
My question is thus:
What functions would I have to use, to make it so I can run a pthread for a few milliseconds, suspend the process, then run another function, then go back and run the process for a few more milli-seconds etc?
OR
If the above isn't possible, what solution is there to the original problem?
Assuming that the "main" thread only cares when the "blocking" thread has completed its work, I think you want condition variables. Look into pthread_cond_wait and pthread_cond_signal.
pthread_join is the function you use to wait for a thread to end.
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
Use pthread_sigmask to manage suspend states:
http://man.yolinux.com/cgi-bin/man2html?cgi_command=pthread_sigmask
You can always use 3 threads, one for each function plus the main thread.
What you need is a queuing mechanism. Your main thread will create 'Jobs'. You then place these 'Jobs' onto your backlog queue where your Worker Thread will pick them up and process then. When the job is done. The worker thread places the now completed 'Jobs' onto the completed queue. You main thread can intermittently check the completed queue and if there is a completed job,it will pick up the 'Job' and do whatever it needs to with it. Your worker thread then goes into a wait state until the next job comes along.
There are numerous ways to roll out the queues. The queue can be a unix pipe. A windows IO Completion Port or you can roll out your own with a linked list/arrays, conditional variables and mutexes.

How can I avoid threading + optimizer == infinite loop? [duplicate]

This question already has answers here:
Multithreading program stuck in optimized mode but runs normally in -O0
(3 answers)
Closed 1 year ago.
In a code review today, I stumbled across the following bit of code (slightly modified for posting):
while (!initialized)
{
// The thread can start before the constructor has finished initializing the object.
// Can lead to strange behavior.
continue;
}
This is the first few lines of code that runs in a new thread. In another thread, once initialization is complete, it sets initialized to true.
I know that the optimizer could turn this into an infinite loop, but what's the best way to avoid that?
volatile - considered harmful
calling an isInitialized() function instead of using the variable directly - would this guarantee a memory barrier? What if the function was declared inline?
Are there other options?
Edit:
Should have mentioned this sooner, but this is portable code that needs to run on Windows, Linux, Solaris, etc. We use mostly use Boost.Thread for our portable threading library.
Calling a function won't help at all; even if a function is not declared inline, its body can still be inlined (barring something extreme, like putting your isInitialized() function in another library and dynamically linking against it).
Two options that come to mind:
Declare initialized as an atomic flag (in C++0x, you can use std::atomic_flag; otherwise, you'll want to consult the documentation for your threading library for how to do this)
Use a semaphore; acquire it in the other thread and wait for it in this thread.
#Karl's comment is the answer. Don't start processing in thread A until thread B has finished initialization. They key to doing this is sending a signal from thread B to thread A that it is up & running.
You mentioned no OS, so I will give you some Windows-ish psudocode. Transcode to the OS/library of your choice.
First create a Windows Event object. This will be used as the signal:
Thread A:
HANDLE running = CreateEvent(0, TRUE, FALSE, 0);
Then have Thread A start Thread B, passing the event along to it:
Thread A:
DWORD thread_b_id = 0;
HANDLE thread_b = CreateThread(0, 0, ThreadBMain, (void*)handle, 0, &thread_b_id);
Now in Thread A, wait until the event is signaled:
Thread A:
DWORD rc = WaitForSingleObject(running, INFINITE);
if( rc == WAIT_OBJECT_0 )
{
// thread B is up & running now...
// MAGIC HAPPENS
}
Thread B's startup routine does its initialization, and then signals the event:
Thread B:
DWORD WINAPI ThreadBMain(void* param)
{
HANDLE running = (HANDLE)param;
do_expensive_initialization();
SetEvent(running); // this will tell Thread A that we're good to go
}
Synchronization primitives are the solution to this problem, not spinning in a loop... But if you must spin in a loop and can't use a semaphore, event, etc, you can safely use volatile. It's considered harmful because it hurts the optimizer. In this case that's exactly what you want to do, no?
There is a boost equivalent of atomic_flag which is called once_flag in boost::once. It may well be what you want here.
Effectively if you want something to be constructed the first time it is called, eg lazy loading, and happens in multiple threads, you get boost::once to call your function the first time it is reached. The post-condition is that it has been initialized so there is no need for any kind of looping or locking.
What you do need to ensure is that your initialization logic does not throw exceptions.
This is a well known problem when working with threads. Creation/Initialization of objects takes relatively little time. When the thread actually starts running though... That can take quite a long time in terms of executed code.
Everyone keeps mentioning semaphores...
You may want to look at POSIX 1003.1b semaphores. Under Linux, try man sem_init. E.g.:
http://manpages.ubuntu.com/manpages/dapper/man3/sem_init.3.html
http://www.skrenta.com/rt/man/sem_init.3.html
http://docs.oracle.com/cd/E23824_01/html/821-1465/sem-init-3c.html
These semaphores have the advantage that, once Created/Initialized, one thread can block indefinitely until signaled by another thread. More critically, that signal can occur BEFORE the waiting thread starts waiting. (A significant difference between Semaphores and Condition Variables.) Also, they can handle the situation where you receive multiple signals before waking up.

CEvent-like behaviour with Boost.Thread

Problem in words:
For my application, I have a class that reads from a serial port. It uses Windows primitives for COM port handling and had a thread for asynchronous reading. I'm trying to convert this away from Windows primitives using Boost libraries such as Boost.Asio and Boost.Thread.
In the Windows port, my IO thread had several MFC CEvent variables, each of which represented a message: Read requested, Write requested, Read completed, Write completed, IO Cancelled. These were waited on with WaitForMultipleObjects.
The problem I have is that Boost.Thread seems to have analogues for neither CEvent nor WaitForMultipleObjects. The closest I have come is by discarding these and replacing the events with a set of booleans, and then using a condition_variable, which has its notify_all() function called whenever a boolean changes.
However, boost::condition_variable differs in one critical way from CEvent: if a CEvent is signalled while it is not being waited on, then the next wait on it immediately succeeds. With boost::condition_variable, any notify function is ignored if it is not waiting.
This means that there is always a gap between checking for the flags and waiting for the condition_variable in which a notification can be lost. This causes the thread to hang.
Does anybody know of a solution to this problem?
Problem in code:
// Old IO Thread
CEvent msg_cancel;
CEvent msg_read_req;
CEvent msg_write_req;
CEvent msg_read_comp;
CEvent msg_write_comp;
CEvent events[] = {
msg_cancel,
msg_read_req,
msg_write_req,
msg_read_comp,
msg_write_comp
};
bool cancel = false;
while (!cancel)
{
switch(WaitForMultipleObjects(5, events, false, INFINITE))
{
case WAIT_OBJECT_0 :
// msg_cancel
cancel = true;
break;
...
}
}
How to emulate that in Boost.Thread?
As you said, to resemble a windows style event you need a condition-variable plus a boolean flag. Of course you can combine several boolean flags into one if it satisfies your needs.
However, the problem you mentioned (condition variables never get an active state where wait will immediately return) is usually solved that way:
condition-variable
mutex
main-thread:
lock(mutex) { start condition-signaling-thread }
while(some predicate) {
condition-variable.wait(mutex)
do-stuff
}
condition-signaling-thread:
loop:
lock(mutex) {
do-whatever
}
condition-variable.notify();
By having the second thread to wait until the mutex is unlocked by the thread which will handle the condition you can ensure that each condition is handled. (Note: In Java the notify() method has to be called within the lock, which, depending on implementation details, could result in worse performance if done in C++, but ensures that the programmer has at least once thought about how to synchronize the firing of the condition with the receiver).
The reason why boost.thread does not provide windows-style events (and posix-semaphores, btw) is that those primitives make it quite easy to screw up. If you do not plan to port your application to another platform, adapting your application to this different style may not be worth it.