Hi, I have an application which starts a number of threads, and I want the application to wait for the threads to finish before exiting. Standard stuff, I know, but never having used threads before I am wondering what the stadard way is to accomplish this. I have (psuedo code) for (each record in database) { thread thrd(func(), data); } I could imagine storing all my thread objects in a list, and then calling join() on each one. For example something like list <thread> threads; for (each rec in db) { thread thrd(func(), data); threads.insert(threads.begin(),thrd); } list<thread>::iterator i; for (i=threads.begin(); i!=threads.end(); i++) { thread t = *i; t.join(); } Does this seem reasonable? Is there a better/standard way? One thing I don't like here is that each join will block, when what I would like to do is something more like join_all(); Thanks, Rich
--- In Boost-Users@y..., "rgalek2002"
Hi,
I have an application which starts a number of threads, and I want the application to wait for the threads to finish before exiting. Standard stuff, I know, but never having used threads before I am wondering what the stadard way is to accomplish this.
I have (psuedo code)
for (each record in database) { thread thrd(func(), data); }
I could imagine storing all my thread objects in a list, and then calling join() on each one. For example something like
list <thread> threads; for (each rec in db) { thread thrd(func(), data); threads.insert(threads.begin(),thrd); } list<thread>::iterator i; for (i=threads.begin(); i!=threads.end(); i++) { thread t = *i; t.join(); }
Does this seem reasonable? Is there a better/standard way?
This is precisely what boost::thread_group was designed for, and it works very similar to your pseudo code.
One thing I don't like here is that each join will block, when what I would like to do is something more like join_all();
There's no "end result" difference between calling join() for each individual thread and calling some "join_all()" method. On platforms like Win32 there might be some subtle performance differences, but probably not enough to be worth considering. Bill Kempf
participants (2)
-
bill_kempf
-
rgalek2002