The following (pseudo-) code induces some behaviour which I dont understand. I have 2 threads running parallel. Both do the same (complex) calculation but I dont know which will finish first. Repeatedly run, there are cases where the first is faster and cases where the second is faster. This is okay and works as intended. Then, the first successfull thread should terminate the other thread and both should fork together. However if the first solver finishs, everything works out but if the second finishes first, the "join command" does not recognize that the first solver is terminated (so the join waits forever, the programm does not continue). Any ideas what I did wrong or what I could do different?
void* thread_function(...)
{
do_some_complex_task();
if (successfull && first_finsihed)
{
pthread_chancel(other_thread);
}
}
int main()
{
std::vector<pthread_t*> store;
store.resize(2);
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
pthread_create(store[0], NULL, thread_function, ...);
pthread_create(store[1], NULL, thread_function, ...);
pthread_join(*store[0], NULL);
pthread_join(*store[1], NULL);
}
PS. If the pseudo code is not detailed enough please let me know.
Based on the pseudo code, one problem may be that the threads have deferred cancellation (the default value) instead of asynchronous cancellation. If the canceled thread never reaches a cancellation point, then pthread_join would block. When calling pthread_create, the newly created thread inherits the calling thread's:
signal mask (pthread_signmask)
floating point environment (fenv)
capabilities
CPU affinity mask (sched_setaffinity)
Try invoking pthread_setcanceltype from within threads you wish to cancel. You may also want to consider attaching a debugger to the program to identify the current state of the threads.
Ideally, if it is at all possible, consider avoiding pthread_cancel. Although the pthread-calls are documented, it can be difficult to obtain and maintain the exact behavior due to all of the minor details. It is generally easier to set a flag that indicates that the thread is set to exit, and begin to return from functions when it is set. In do_some_complex_task, consider breaking the complex task into smaller tasks, and check for cancellation between each smaller task.
Don't use pthread_cancel - use a global state, and check it inside the "main loop" of each thread . Set it "on" just before the exit of the thread's function.
Related
I am creating multiple threads in my program. On pressing Ctrl-C, a signal handler is called. Inside a signal handler, I have put exit(0) at last. The thing is that sometimes the program terminates safely but the other times, I get runtime error stating
abort() has been called
So what would be the possible solution to avoid the error?
The usual way is to set an atomic flag (like std::atomic<bool>) which is checked by all threads (including the main thread). If set, then the sub-threads exit, and the main thread starts to join the sub-threads. Then you can exit cleanly.
If you use std::thread for the threads, that's a possible reason for the crashes you have. You must join the thread before the std::thread object is destructed.
Others have mentioned having the signal-handler set a std::atomic<bool> and having all the other threads periodically check that value to know when to exit.
That approach works well as long as all of your other threads are periodically waking up anyway, at a reasonable frequency.
It's not entirely satisfactory if one or more of your threads is purely event-driven, however -- in an event-driven program, threads are only supposed to wake up when there is some work for them to do, which means that they might well be asleep for days or weeks at a time. If they are forced to wake up every (so many) milliseconds simply to poll an atomic-boolean-flag, that makes an otherwise extremely CPU-efficient program much less CPU-efficient, since now every thread is waking up at short regular intervals, 24/7/365. This can be particularly problematic if you are trying to conserve battery life, as it can prevent the CPU from going into power-saving mode.
An alternative approach that avoids polling would be this one:
On startup, have your main thread create an fd-pipe or socket-pair (by calling pipe() or socketpair())
Have your main thread (or possibly some other responsible thread) include the receiving-socket in its read-ready select() fd_set (or take a similar action for poll() or whatever wait-for-IO function that thread blocks in)
When the signal-handler is executed, have it write a byte (any byte, doesn't matter what) into the sending-socket.
That will cause the main thread's select() call to immediately return, with FD_ISSET(receivingSocket) indicating true because of the received byte
At that point, your main thread knows it is time for the process to exit, so it can start directing all of its child threads to start shutting down (via whatever mechanism is convenient; atomic booleans or pipes or something else)
After telling all the child threads to start shutting down, the main thread should then call join() on each child thread, so that it can be guaranteed that all of the child threads are actually gone before main() returns. (This is necessary because otherwise there is a risk of a race condition -- e.g. the post-main() cleanup code might occasionally free a resource while a still-executing child thread was still using it, leading to a crash)
The first thing you must accept is that threading is hard.
A "program using threading" is about as generic as a "program using memory", and your question is similar to "how do I not corrupt memory in a program using memory?"
The way you handle threading problem is to restrict how you use threads and the behavior of the threads.
If your threading system is a bunch of small operations composed into a data flow network, with an implicit guarantee that if an operation is too big it is broken down into smaller operations and/or does checkpoints with the system, then shutting down looks very different than if you have a thread that loads an external DLL that then runs it for somewhere from 1 second to 10 hours to infinite length.
Like most things in C++, solving your problem is going to be about ownership, control and (at a last resort) hacks.
Like data in C++, every thread should be owned. The owner of a thread should have significant control over that thread, and be able to tell it that the application is shutting down. The shut down mechanism should be robust and tested, and ideally connected to other mechanisms (like early-abort of speculative tasks).
The fact you are calling exit(0) is a bad sign. It implies your main thread of execution doesn't have a clean shutdown path. Start there; the interrupt handler should signal the main thread that shutdown should begin, and then your main thread should shut down gracefully. All stack frames should unwind, data should be cleaned up, etc.
Then the same kind of logic that permits that clean and fast shutdown should also be applied to your threaded off code.
Anyone telling you it is as simple as a condition variable/atomic boolean and polling is selling you a bill of goods. That will only work in simple cases if you are lucky, and determining if it works reliably is going to be quite hard.
Additional to Some programmer dude answer and related to discussion in the comment section, you need to make the flag that controls termination of your threads as atomic type.
Consider following case :
bool done = false;
void pending_thread()
{
while(!done)
{
std::this_thread::sleep(std::milliseconds(1));
}
// do something that depends on working thread results
}
void worker_thread()
{
//do something for pending thread
done = true;
}
Here worker thread can be your main thread also and done is terminating flag of your thread, but pending thread need to do something with given data by working thread, before exiting.
this example has race condition and undefined behaviour along with it, and it's really hard to find what is the actual problem int the real world.
Now the corrected version using std::automic :
std::atomic<bool> done(false);
void pending_thread()
{
while(!done.load())
{
std::this_thread::sleep(std::milliseconds(1));
}
// do something that depends on working thread results
}
void worker_thread()
{
//do something for pending thread
done = true;
}
You can exit thread without being concern of race condition or UB.
Say I have a function whose prototype looks like this, belonging to class container_class:
std::vector<int> container_class::func(int param);
The function may or may not cause an infinite loop on certain inputs; it is impossible to tell which inputs will cause a success and which will cause an infinite loop. The function is in a library of which I do not have the source of and cannot modify (this is a bug and will be fixed in the next release in a few months, but for now I need a way to work around it), so solutions which modify the function or class will not work.
I've tried isolating the function using std::async and std::future, and using a while loop to constantly check the state of the thread:
container_class c();
long start = get_current_time(); //get the current time in ms
auto future = std::async(&container_class::func, &c, 2);
while(future.wait_for(0ms) != std::future_status::ready) {
if(get_current_time() - start > 1000) {
//forcibly terminate future
}
sleep(2);
}
This code has many problems. One is that I can't forcibly terminate the std::future object (and the thread that it represents).
At the far extreme, if I can't find any other solution, I can isolate the function in its own executable, run it, and then check its state and terminate it appropriately. However, I would rather not do this.
How can I accomplish this? Is there a better way than what I'm doing right now?
You are out of luck, sorry.
First off, C++ doesn't even guarantee you there will be a thread for future execution. Although it would be extremely hard (probably impossible) to implement all std::async guarantees in a single thread, there is no direct prohibition of that, and also, there is certainly no guarantee that there will be a thread per async call. Because of that, there is no way to cancel the async execution.
Second, there is no such way even in the lowest level of thread implementation. While pthread_cancel exists, it won't protect you from infinite loops not visiting cancellation points, for example.
You can not arbitrarily kill a thread in Posix, and C++ thread model is based on it. A process really can't be a scheduler of it's own threads, and while sometimes it is a pain, it is what it is.
I am new to multi-threading. I am using c++ on unix.
In the code below, runSearch() takes a long time and I want to be able to kill the search as soon as "cancel == true". The function cancelSearch is called by another thread.
What is the best way to solve this problem?
Thanks you..
------------------This is the existing code-------------------------
struct SearchTask : public Runnable
{
bool cancel = false;
void cancelSearch()
{
cancel = true;
}
void run()
{
cancel = false;
runSearch();
if (cancel == true)
{
return;
}
//...more steps.
}
}
EDIT: To make it more clear, say runSearch() takes 10 mins to run. After 1 min, cancel==true, then I want to exit out of run() immediately rather than waiting another 9 more mins for runSearch() to complete.
You'll need to keep checking the flag throughout the search operation. Something like this:
void run()
{
cancel = false;
while (!cancel)
{
runSearch();
//do your thread stuff...
}
}
You have mentioned that you cannot modify runSearch(). With pthreads there's a pthread_setcancelstate() function, however I don't believe this is safe, especially with C++ code that expects RAII semantics.
Safe thread cancellation must be cooperative. The code that gets canceled must be aware of the cancellation and be able to clean up after itself. If the code is not designed to do this and is simply terminated then your program will probably exhibit undefined behavior.
For this reason C++'s std::thread does not offer any method of thread cancellation and instead the code must be written with explicit cancellation checks as other answers have shown.
Create a generic method that accepts a action / delegate. Have each step be something REALLY small and specific. Send the generic method a delegate / action of what you consider a "step". In the generic method detect if cancel is true and return if true. Because steps are small if it is cancelled it shouldn't take long for the thread to die.
That is the best advice I can give without any code of what the steps do.
Also note :
void run()
{
cancel = false;
runSearch();
while (!cancel)
{
//do your thread stuff...
}
}
Won't work because if what you are doing is not a iteration it will run the entire thread before checking for !cancel. Like I said if you can add more details on what the steps do it would easier to give you advice. When working with threads that you want to halt or kill, your best bet is to split your code into very small steps.
Basically you have to poll the cancel flag everywhere. There are other tricks you could use, but they are more platform-specific, like thread cancellation, or are not general enough like interrupts.
And cancel needs to be an atomic variable (like in std::atomic, or just protected it with a mutex) otherwise the compiler might just cache the value in a register and not see the update coming from another thread.
Reading the responses is right - just because you've called a blocking function in a thread doesn't mean it magically turns into a non-blocking call. The thread may not interrupt the rest of the program, but it still has to wait for the runSearch call to complete.
OK, so there are ways round this, but they're not necessarily safe to use.
You can kill a thread explicitly. On Windows you can use TerminateThread() that will kill the thread execution. Sound good right? Well, except that it is very dangerous to use - unless you know exactly what all the resources and calls are going on in the killed thread, you may find yourself with an app that refuses to work correctly next time round. If runSearch opens a DB connection for example, the TerminateThread call will not close it. Same applies to memory, loaded dlls, and all they use. Its designed for killing totally unresponsive threads so you can close a program and restart it.
Given the above, and the very strong recommendation you not use it, the next step is to call the runSearch in a external manner - if you run your blocking call in a separate process, then the process can be killed with a lot more certainty that you won't bugger everything else up. The process dies, clears up its memory, its heap, any loaded dlls, everything. So inside your thread, call CreateProcess and wait on the handle. You'll need some form on IPC (probably best not to use shared memory as it can be a nuisance to reset that when you kill the process) to transfer the results back to your main app. If you need to kill this process, call ExitProcess on it's handle (or exit in Linux)
Note that these exit calls require to be called inside the process, so you'll need to run a thread inside the process for your blocking call. You can terminate a process externally, but again, its dangerous - not nearly as dangerous as killing a thread, but you can still trip up occasionally. (use TerminateProcess or kill for this)
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 :)
In my code, I use QueueUserAPC to interrupt the main thread from his current work in order to invoke some callback first before going back to his previous work.
std::string buffer;
std::tr1::shared_ptr<void> hMainThread;
VOID CALLBACK myCallback (ULONG_PTR dwParam) {
FILE * f = fopen("somefile", "a");
fprintf(f, "CALLBACK WAS INVOKED!\n");
fclose(f);
}
void AdditionalThread () {
// download some file using synchronous wininet and store the
// HTTP response in buffer
QueueUserAPC(myCallback, hMainThread.get(), (ULONG_PTR)0);
}
void storeHandle () {
HANDLE hUnsafe;
DuplicateHandle(GetCurrentProcess(), GetCurrentThread(),
GetCurrentProcess(), &hUnsafe, 0, FALSE, DUPLICATE_SAME_ACCESS);
hMainThread.reset(hUnsafe, CloseHandle);
}
void startSecondThread () {
CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)AdditionalThread, 0, 0, NULL);
}
storeHandle and startSecondThread are exposed to a Lua interpreter which is running in the main thread along with other things. What I do now, is
invoke storeHandle from my Lua interpreter. DuplicateHandle returns a non-zero value and therefore succeeds.
invoke startSecondThread from my Lua interpreter. The additional thread gets started properly, and QueueUserAPC returns a nonzero value, stating, that all went well.
as far as I understood QueueUserAPC, myCallback should now get called from the main thread. However, it doesn't.
If QueueUserAPC is the correct way to accomplish my goal (==> see my other question):
How can I get this working?
If I should some other method to interrupt the main thread:
What other method should I use? (Note that I don't want to use pull-ing method in the main thread for this like WaitForSingleObject or polling. I want that the additional thread push-es it's data straight into the main thread, as soon as possible.)
Yeah, QueueUserAPC is not the solution here. Its callback will only run when the thread blocks and the programmer has explicitly allowed the wait to be alertable. That's unlikely.
I hesitate to post the solution because it is going to get you into enormous trouble. You can implement a thread interrupt with SuspendThread(), GetThreadContext(), SetThreadContext() and ResumeThread(). The key is to save the CONTEXT.Eip value on the thread's call stack and replace it with the address of the interrupt function.
The reason you cannot make this work is because you'll have horrible re-entrancy problems. There is no way you can guess at which point of execution you'll interrupt the thread. It may well be right in the middle of it mutating state, the state that you need so badly that you are contemplating doing this. There is no way to not fall into this trap, you can't block it with a mutex or whatnot. It is also extremely hard to diagnose because it will work so well for so long, then randomly fail when the interrupt timing just happens to be unlucky.
A thread must be in a well known state before it can safely run injected code. The traditional one has been mentioned many times before: when a thread is pumping a message loop is is implicitly idle and not doing anything dangerous. QueueUserAPC has the same approach, a thread explicitly signals the operating system that it is a state where the callback can be safely executed. Both by blocking (not executing dangerous code) and setting the bAlertable flag.
A thread has to explicitly signal that it is in a safe state. There is no safe push model, only pull.
From what I can understand in MSDN, the callback is not invoked until the thread enters an alertable state, and this is done by calling SleepEx, SignalObjectAndWait, WaitForSingleObjectEx, WaitForMultipleObjectsEx, or MsgWaitForMultipleObjectsEx.
So if you really don't want to do some polling, I don't think this method is adapted to your case.
Is it possible to implement a "message pump" (or rather an event listener) in your main thread and to delegate all its current work to another thread ? In this case, the main thread waits for any event that are set by the other threads.