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.
Related
I have a program, where there are multiple threads running in an infinite loop. Each thread can handling a certain number of tasks say MAXTASKFOREACHTHREAD. A new thread is generated when the number of tasks increases. If MAXTASKFOREACHTHREAD is not reached, new task will be added into it. But if the task is completed such that number of task in a thread = 0, at a particular point. I want to terminate that thread. I don't want that thread to keep waiting for a task. A new thread can be spawned as needed.
class ThreadPool
{
void createThread();
static void threadFunc(ThreadPool *);
private:
thread t;
int val = 0;
}
void ThreadPool::createThread()
{
t = thread(threadFunc, this);
}
void ThreadPool::threadFunc();
//carries the function implementation regarding tasks
int main()
{
vector<ThreadPool *> v;
v.push_back(new ThreadPool());
v.push_back(new ThreadPool());
v.push_back(new ThreadPool());
v[0].createThread();
v[1].createThread();
v[2].createThread();
}
// Code might have syntax error, I just typed out!
// Now how should I proceed with the deletion of thread, without causing memory corruption!, I need to delete the corresponing object, of the thread
// I am looking for a idea, how to deal with this, without increasing the complexity by using locks.
Please give some suggestions!
If any part is not clear that add in comments.
It seems that you're forgetting that threads run code. You can simply use the worker thread itself to check if there's more work.
First, let's clear up some confusion. A ThreadPool holds multiple threads. In your case, v would be that pool. std::vector is not really a convenient interface for that. So, rename your existing ThreadPool to WorkerThread, and create a ThreadPool with a private: std::vector<WorkerThread>. (objects, not pointers)
The WorkerThread cooperates with ThreadPool. Your WorkerThread::threadFunc has a main loop that checks if there is work. If so, it's executed. But if there's no work, that's the case where you retire the thread. You exit the thread main loop, tell the ThreadPool you're done, and let it call join. Alternatively, detach the WorkerThreads.
Another way to remove threads is to make a special task in the ThreadPool, which causes the WorkerThread which picks it up to exit its main loop. This could be implemented as an empty std::function<>, for instance. In this way, you can actively reduce the number of threads, even if there is work left.
Suppose I have created 10 pthreads using a for loop in a C++ application on Linux. All these 10 threads are calling the same thread function. I want the last exiting thread (between [1..10]) to call a function where I can clear some data. Is there any pthread function like that? (Not talking about thread specific data and pthread_once())
Note: Requirement is not with std::thread here.
If you want the last thread that exits to perform the work then have all 10 threads decrement a counter that starts off set to the number of threads. If you're using std::atomic then when you do a fetch_sub and get back the value 1 you'll know you are the last thread running and can perform the work:
int threads_active = atomic_threads_active.fetch_sub(1);
if (threads_active == 1)
{
// We are the last thread of the 10 that were launched.
clearSomeData();
}
I don't know about a specific function for that, but you can simply join all 10 threads in a loop. Once all threads have joined, you can execute the function. You can do this in the thread that spawned the 10 threads or in a separate thread if you so prefer.
i had to detach all the threads
That's not a very good choice if you want to wait for them to exit.
But you can work around it by using a shared array of 10 condition variables. Each of the threads should set the variable corresponding to it and call pthread_cond_signal. The waiter should use pthread_cond_wait in a loop to wait for each of the condition variables to be set.
In this case, main() calls func1(), func1() creates a pthread_t pointer which points to arrays of pthread_ts( pthread_t *tid = new pthread_t[10]). And creates 10 threads in for loop. After creation, control will be returned to main(), main() has other tasks to do. Now, the problem is how can i remove (tid) from heap memory?
You can simply do as I suggested. Don't detatch the threads, but wait for the threads to join in a loop. Once they're finished, you are free to destroy the thread objects. You can do this in a separate thread as I said. No need for the main thread to wait anything.
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.
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.
Using POSIX threads & C++, I have an "Insert operation" which can only be done safely one at a time.
If I have multiple threads waiting to insert using pthread_join then spawning a new thread
when it finishes. Will they all receive the "thread complete" signal at once and spawn multiple inserts or is it safe to assume that the thread that receives the "thread complete" signal first will spawn a new thread blocking the others from creating new threads.
/* --- GLOBAL --- */
pthread_t insertThread;
/* --- DIFFERENT THREADS --- */
// Wait for Current insert to finish
pthread_join(insertThread, NULL);
// Done start a new one
pthread_create(&insertThread, NULL, Insert, Data);
Thank you for the replies
The program is basically a huge hash table which takes requests from clients through Sockets.
Each new client connection spawns a new thread from which it can then perform multiple operations, specifically lookups or inserts. lookups can be conducted in parallel. But inserts need to be "re-combined" into a single thread. You could say that lookup operations could be done without spawning a new thread for the client, however they can take a while causing the server to lock, dropping new requests. The design tries to minimize system calls and thread creation as much as possible.
But now that i know it's not safe the way i first thought I should be able to cobble something together
Thanks
From opengroup.org on pthread_join:
The results of multiple simultaneous calls to pthread_join() specifying the same target thread are undefined.
So, you really should not have several threads joining your previous insertThread.
First, as you use C++, I recommend boost.thread. They resemble the POSIX model of threads, and also work on Windows. And it helps you with C++, i.e. by making function-objects usable more easily.
Second, why do you want to start a new thread for inserting an element, when you always have to wait for the previous one to finish before you start the next one? Seems not to be classical use of multiple-threads.
Although... One classical solution to this would be to have one worker-thread getting jobs from an event-queue, and other threads posting the operation onto the event-queue.
If you really just want to keep it more or less the way you have it now, you'd have to do this:
Create a condition variable, like insert_finished.
All the threads which want to do an insert, wait on the condition variable.
As soon as one thread is done with its insertion, it fires the condition variable.
As the condition variable requires a mutex, you can just notify all waiting threads, they all want start inserting, but as only one thread can acquire the mutex at a time, all threads will do the insert sequentially.
But you should take care that your synchronization is not implemented in a too ad-hoc way. As this is called insert, I suspect you want to manipulate a data-structure, so you probably want to implement a thread-safe data-structure first, instead of sharing the synchronization between data-structure-accesses and all clients. I also suspect that there will be more operations then just insert, which will need proper synchronization...
According to the Single Unix Specifcation: "The results of multiple simultaneous calls to pthread_join() specifying the same target thread are undefined."
The "normal way" of achieving a single thread to get the task would be to set up a condition variable (don't forget the related mutex): idle threads wait in pthread_cond_wait() (or pthread_cond_timedwait()), and when the thread doing the work has finished, it wakes up one of the idle ones with pthread_cond_signal().
Yes as most people recommended the best way seems to have a worker thread reading from a queue. Some code snippets below
pthread_t insertThread = NULL;
pthread_mutex_t insertConditionNewMutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t insertConditionDoneMutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t insertConditionNew = PTHREAD_COND_INITIALIZER;
pthread_cond_t insertConditionDone = PTHREAD_COND_INITIALIZER;
//Thread for new incoming connection
void * newBatchInsert()
{
for(each Word)
{
//Push It into the queue
pthread_mutex_lock(&lexicon[newPendingWord->length - 1]->insertQueueMutex);
lexicon[newPendingWord->length - 1]->insertQueue.push(newPendingWord);
pthread_mutex_unlock(&lexicon[newPendingWord->length - 1]->insertQueueMutex);
}
//Send signal to worker Thread
pthread_mutex_lock(&insertConditionNewMutex);
pthread_cond_signal(&insertConditionNew);
pthread_mutex_unlock(&insertConditionNewMutex);
//Wait Until it's finished
pthread_cond_wait(&insertConditionDone, &insertConditionDoneMutex);
}
//Worker thread
void * insertWorker(void *)
{
while(1)
{
pthread_cond_wait(&insertConditionNew, &insertConditionNewMutex);
for (int ii = 0; ii < maxWordLength; ++ii)
{
while (!lexicon[ii]->insertQueue.empty())
{
queueNode * newPendingWord = lexicon[ii]->insertQueue.front();
lexicon[ii]->insert(newPendingWord->word);
pthread_mutex_lock(&lexicon[ii]->insertQueueMutex);
lexicon[ii]->insertQueue.pop();
pthread_mutex_unlock(&lexicon[ii]->insertQueueMutex);
}
}
//Send signal that it's done
pthread_mutex_lock(&insertConditionDoneMutex);
pthread_cond_broadcast(&insertConditionDone);
pthread_mutex_unlock(&insertConditionDoneMutex);
}
}
int main(int argc, char * const argv[])
{
pthread_create(&insertThread, NULL, &insertWorker, NULL);
lexiconServer = new server(serverPort, (void *) newBatchInsert);
return 0;
}
The others have already pointed out this has undefined behaviour. I'd just add that the really simplest way to accomplish your task (to allow only one thread executing part of code) is to use a simple mutex - you need the threads executing that code to be MUTally EXclusive, and that's where mutex came to its name :-)
If you need the code to be ran in a specific thread (like Java AWT), then you need conditional variables. However, you should think twice whether this solution actually pays off. Imagine, how many context switches you need if you call your "Insert operation" 10000 times per second.
As you just now mentioned you're using a hash-table with several look-ups parallel to insertions, I'd recommend to check whether you can use a concurrent hash-table.
As the exact look-up results are non-deterministic when you're inserting elements simultaneously, such a concurrent hash-map may be exactly what you need. I do not have used concurrent hash-tables in C++, though, but as they are available in Java, you'll for sure find a library doing this in C++.
The only library which i found which supports inserts without locking new lookups - Sunrise DD (And i'm not sure whether it supports concurrent inserts)
However the switch from Google's Sparse Hash map more than doubles the memory usage. Lookups should happen fairly infrequently so rather than trying and write my own library
which combines the advantages of both i would rather just lock the table suspending lookups while changes are made safely.
Thanks again
It seems to me that you want to serialise inserts to the hashtable.
For this you want a lock - not spawning new threads.
From your description that looks very inefficient as you are re-creating the insert thread every time you want to insert something. The cost of creating the thread is not 0.
A more common solution to this problem is to spawn an insert thread that waits on a queue (ie sits in a loop sleeping while the loop is empty). Other threads then add work items to the queue. The insert thread picks items of the queue in the order they were added (or by priority if you want) and does the appropriate action.
All you have to do is make sure addition to the queue is protected so that only one thread at a time has accesses to modifying the actual queue, and that the insert thread does not do a busy wait but rather sleeps when nothing is in the queue (see condition variable).
Ideally,you dont want multiple threadpools in a single process, even if they perform different operations. The resuability of a thread is an important architectural definition, which leads to pthread_join being created in a main thread if you use C.
Ofcourse, for a C++ threadpool aka ThreadFactory , the idea is to keep the thread primitives abstract so, it can handle any of function/operation types passed to it.
A typical example would be a webserver which will have connection pools and thread pools which service connections and then process them further, but, all are derived from a common threadpool process.
SUMMARY : AVOID PTHREAD_JOIN IN any place other than a main thread.