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

Question

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!

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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 :)