I have an array of std::thread objects that it doesn't matter what order they operate in and what order they rejoin the main thread. I've tried using
for(int i = 0; i < noThreads; ++i)
{
if(threads[i].joinable())
threads[i].join();
}
but that seems to make them operate "in order", of course that could be the fact that i'm reaching that conclusion from the fact that the console output from the threads is happening in the order that I dispatch them in (as in all of the output from thread #1 then all of the output from thread #2). I have also attempted threads[i].detach(), but I don't know the execution time of each thread, so I can't pause the program until they have finished.
The work that each thread is doing is:
int spawn(const char* cmd)
{
FILE *fp = popen(cmd, "r");
char buff[512];
if(vFlag == 1)
{
while(fgets(buff, sizeof(buff), fp)!= NULL)
{
printf("%s", buff);
}
}
int w = pclose(fp);
if(WIFEXITED(w))
return WEXITSTATUS(w);
else
return -1;
}
where the command being executed is "./otherApp.elf". Bearing in mind that the current fact that it is being printed out to console will change to being output to various files, how do I dispatch the threads so that I can make them execute then rejoin out of order?
Execution order is not influenced by join order. So you can simply call join in a loop to join all the threads.
A second thing worth pointing out is that joinable doesn't mean whether a thread has finished execution. See the link for a detailed explanation.
If you really want to check whether a thread has finished execution there might be other ways to do it as described here.
Boost already has extensions to wait for any or all of a set of futures and testing functions to see whether a thread has finished execution.
The for cycle you are using is giving you the order of joining (NOT the threads execution order).
I mean that the join function is blocking the process in waiting for the thread to complete, so if you check the threads with the for cycle you're using, you'll block your main process on the first join even if (i.e.) the last thread is already finished.
As you can see i.e. here, the joinable method is meaning something like: is this thread started (or maybe finished) and not already joined?
So if you need to know if a thread is finished, I think you can use something like a semaphore linked to each thread and check its value in a cycle. So you'll not block the main process and you'll join threads almost in their finishing order.
Related
I've got a class named TThreadpool, which holds member pool of type std::vector<std::thread>>, with the following destructor:
~TThreadpool() {
for (size_t i = 0; i < pool.size(); i++) {
assert(pool[i].joinable());
pool[i].join();
}
}
I'm confident that when destructor is called, all of the threads are waiting on a single condition variable (spurious wakeup controlled with always-false predicate), and joinable outputs true.
Reduced example of running thread would be:
void my_thread() {
std::unique_lock<std::mutex> lg(mutex);
while (true) {
my_cond_variable.wait(lg, [] {
return false;
});
# do some work and possibly break, but never comes farther then wait
# so this probably should not matter
}
}
To check what threads are running, I'm launching top -H. At the start of the program, there are pool.size() threads + 1 thread where TThreadpool itself lives. And to my surprise, joining these alive threads does not remove them from list of threads that top is giving. Is this expected behaviour?
(Originally, my program was a bit different - I made a simple ui application using qt, that used threadpool running in ui thread and other threads controlled by threadpool, and on closing the ui window joining of threads had been called, but QtCreator said my application still worked after I closed the window, requiring me to shut it down with a crash. That made me check state of my threads, and it turned out it had nothing to do with qt. Although I'm adding this in case I missed some obvious detail with qt).
A bit later, I tried not asserting joinable, but printing it, and found out the loop inside Threadpool destructor never moved further than first join - the behaviour I did not expect and cannot explain
join() doesn't do anything to the child thread -- all it does is block until the child thread has exited. It only has an effect on the calling thread (i.e. by blocking its progress). The child thread can keep running for as long as it wants (although typically you'd prefer it to exit quickly, so that the thread calling join() doesn't get blocked for a long time -- but that's up to you to implement)
And to my surprise, joining these alive threads does not remove them from list of threads that top is giving. Is this expected behaviour?
That suggests the thread(s) are still running. Calling join() on a thread doesn't have any impact on that running thread; simply the calling thread
waits for the called-on thread to exit.
found out the loop inside Threadpool destructor never moved further than first join
That means the first thread hasn't completed yet. So none of the other threads haven't been joined yet either (even if they have exited).
However, if the thread function is implemented correctly, the first thread (and all other threads in the pool) should eventually complete and
the join() calls should return (assuming the threads in the pool are supposed to exit - but this doesn't need to true in general.
Depending on application, you could simply make the threads run forever too).
So it appears there's some sort of deadlock or wait for some resource that's holding up one or more threads. So you need to run through a debugger.
Helgrind would be very useful.
You could also try to reduce the number of threads (say 2) and to see if the problem becomes reproducible/obvious and then you could increase the threads.
I have a vector of threads that I collect during the execution of my application. To avoid some nasty behavior, I'm trying to ensure every thread is completed when the main thread exits. I tried to call std::thread::join on each thread in the vector upon a termination event, but it seems to get stuck if the most recent thread hasn't finished its work and won't stop blocking even after it should. It's important to note that ThingMaker::CreateThing reads frames from a series of video files and writes them all to one video, so I know the thread should finish its work in less time than the length of the video clip being created.
std::vector<std::thread> threadList;
while (!done)
{
switch (triggerEvent)
{
case 'h': // Spawn new thread to make a thing "in the background"
{
ThingMaker next_thing = new ThingMaker();
threadList.push_back(std::thread(&ThingMaker::CreateThing, next_thing));
next_thing = NULL;
break;
}
case 't': // Terminate the application
{
std::vector<std::thread>::iterator threads;
for (threads = threadList.begin(); threads != threadList.end(); ++threads)
threads->join();
done = true;
break;
}
default: break;
}
}
If I send a 't' before the most recent thread has finished making the video clip and thus finished altogether, threads->join() blocks forever. However, if i wait for all video clips to be created, the application terminates. To my understanding, it should simply wait for the thread to finish its work and then let the main thread carry on - is this a misunderstanding?
There are two possibilities:
The thread simply hasn't finished yet. You can add logging to your code or use a debugger to see whether this is the case.
The thread that called join holds some lock that is preventing the other thread from finishing. Calling join waits for a thread to finish and cannot be safely called unless you're absolutely sure that thread that calls join holds no locks the other thread might need to acquire in order to finish. (Look closely at the call stack leading to the call to join to see if this is a posssibility.)
There are two issues in your code:
The join() on an active thread will wait that the thread is finished before continuing anything. So if you have no mechanism to to tell your threads to stop (e.g. a shared atomic variable), you'll wait forever.
Your threadlist vector is inside the while loop, so that it's a new list on every occurence. What happens to the thread that you have pushed into it ? It gets destroyed, and as join() wasn't called, it will terminate() your programme.
With std::thread you must ensure that each thread is made unjoinable (that typically means calling .join()), exactly once. Clearly, a call to .join() will wait for that thread to complete. Start a debug session and have a look what each of the threads are doing.
The code you have shown (which is still woefully incomplete and so we're just guessing) doesn't remove thread objects from the vector after you join them. That means you will try to rejoin an already joined thread on the next time through the loop. Trying to join a thread that is not joinable has undefined behaviour. It could block forever (because there is no such thread so it can never be joined).
You should either:
only try to join threads that are joinable:
case 't': // Terminate the application
{
for (auto& t : threadList)
if (t.joinable())
t.join();
done = true;
break;
}
or remove the threads from the list after they've been joined:
case 't': // Terminate the application
{
for (auto& t : threadList)
t.join();
threadList.clear();
done = true;
break;
}
I have the following code:
void do_join(std::thread& t)
{
t.join();
}
void join_all(std::vector<std::thread>& v)
{
std::for_each(v.begin(),v.end(),do_join);
}
int main()
{
std::vector<std::thread> myThreads;
for(int i = 1; i <= 3; i++)
{
myThreads.push_back(std::thread(threadMethod));
}
join_all(myThreads);
}
The goal is to create multiple threads in a loop, add them to a thread vector and then iterating through the vector join them to the main thread.
The problem here is that when my do_join method executes for the first time it joins the thread and waits, not joining any other threads from a vector. That is because my threads are using some conditional variables and waiting for some other tasks to complete. Seems like that do_join method is waiting for just joined thread to complete.
The same thing happens if I try to do for_each directly in the main function.
The idea is to be able to join all these threads to the main thread, not to that let's say do_join's method thread which I suppose happened here. I could of course join and create them separately, because actually I don't need them to be in a vector (the number of threads is known from the beginning), but I need a vector because each thread in my application is actually created using different method's parameters which I did not included in that sample code. I just do not want a new line for every single thread being created and joined.
Thank you for any help!
Edit:
Maybe worth mentioning is that I'm using Ubuntu.
The join method by definition blocks current thread until the one you are trying to join is done:
Blocks the current thread until the thread identified by *this
finishes its execution.
(From here.)
That is, it’s the purpose of join to block its thread until the other one finishes. If you don’t want the thread to be blocked, then don’t use join.
You should ask yourself the question: what are you trying to achieve? If you want your main program to proceed only when all the other threads are done, then what you are doing now is right, you’ll have to wait for all the threads anyway. Otherwise you might need some way for other threads to signal the main one that they are done.
I'm new to thread in C++ 11. I have two threads and I want to make them start at the exact same time. I could think of two ways of doing it (as below). However, it seems that none of them work as I expected. They are start one thread before launching another. Any hint would be appreciated! Another question is I'm working on a threaded queue. So I would have two consumers and four producers. Is the following code for consumer the right way to go? Is there any reference that anyone can provide?
for(int i = 1; i <= 2; i++)
auto c = async(launch::async, consumer, i);
auto c1 = async(launch::async, consumer, 1);
auto c2 = async(launch::async, consumer, 2);
What the other answers said about it not being possible to guarantee that two threads start at the same time is true. Still, if you want to come close there are different ways to do that.
One way is to use a set of std::promises to indicate when everything is ready. Each thread sets a promise to indicate that it's ready and then waits on a (copy of a) std::shared_future obtained from a third std::promise; the main thread waits for all the promises from all the threads to be set and then triggers the threads to go. This ensures that each thread has started and is just before the chunk of code that should be run concurrently.
std::promise<void> go, ready1, ready2; // Promises for ready and go signals
std::shared_future<void> ready(go.get_future()); // Get future for the go signal
std::future<void> done1, done2; // Get futures to indicate that threads have finished
try
{
done1 = std::async(std::launch::async,
[ready, &ready1]
{
ready1.set_value(); // Set this thread's ready signal
ready.wait(); // Wait for ready signal from main thread
consumer(1);
});
done2 = std::async(std::launch::async,
[ready, &ready2]
{
ready2.set_value(); // Set this thread's ready signal
ready.wait(); // Wait for ready signal from main thread
consumer(2);
});
// Wait for threads to ready up
ready1.get_future().wait();
ready2.get_future().wait();
// Signal threads to begin the real work
go.set_value();
// Wait for threads to finish
done1.get();
done2.get();
}
catch (...)
{
go.set_value(); // Avoid chance of dangling thread
throw;
}
Note: most of this answer was copied from "C++ Concurrency in Action" by Anthony Williams (pages 311-312), but I adapted the code to fit the example in the question.
to launch two threads simultaneously I see no other way than first launching 2 threads the classic way, then blocking them using a barrier to synchronize them, but the release broadcast has no guarantee of re-scheduling them both at the same time.
Alternatively you could spin check a global time counter or something but even then...
It is impossible to start two threads at one time. The CPU can only do one thing at a time. It threads by stopping one thread, saving register states, and restoring those of the other thread, and executing that thread for a while. Think of it more like this (though not exactly how it works).
hey cpu, i want to do two things at once, eat apples and bananas
CPU says
ok, well, heres what we will do. Eat a bit of an apple
now, eat some banana
repeat..
Therefore, you can start them in close proximity, but not at the exact same time.
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.