8

I m creating about 300 boost threads in a process. Is there any way to join a specific thread based on the thread id ?

manlio
  • 18,345
  • 14
  • 76
  • 126
sri
  • 165
  • 1
  • 7

1 Answers1

9

It heavenly depends on how you save the boost::threads. If you save them in a container (with T = boost::thread*), you can simply use something like

for(iterator it = ctn.begin(); it != ctn.end(); ++it){
    if(it->get_id() == join_thread_id){
        it->join();
        break;
    }        
}

However, if you don't save your threads somewhere and just use new boost::thread without saving the pointer it's not possible since boost doesn't provide any automatic bookkeeping functionality.

1. Remark: Keep in mind that you'll need to use boost::thread::id to save the id.
2. Remark: std::map<boost::thread::id,boost::thread*> might come in handy for such tasks.

Zeta
  • 103,620
  • 13
  • 194
  • 236
  • 1
    or `find_if(begin(ctn), end(ctn), [join_thread_id](iterator it) { return it->get_id() == join_thread_id;});` – Sebastian Mach Dec 19 '12 at 12:14
  • If there are a lot of threads, isn't better the map?. I'm asking this with performance in mind. – Adri C.S. Dec 19 '12 at 12:16
  • @AdriC.S.: It depends on the meaning of `a lot of`. A map scales nice with the number of arguments (sub-linear lookup complexity), but depending on the actual number of items, a small vector may outperform a small map. – Sebastian Mach Dec 19 '12 at 12:19
  • @phresnel: I don't think that OP uses C++11, that's why I didn't use lambdas ;). – Zeta Dec 19 '12 at 12:20
  • 1
    @AdriC.S.: Heavily depends on how many threads are going to be `join`ed manually. A single lookup will take O(log n) instead of O(n), however, it takes O(n log n) to build the map instead of O(n). If there is only a small constant number a vector will be much faster, but if you join like half the threads a map is better. – Zeta Dec 19 '12 at 12:21
  • These threads dont perform complex functionality .. primary purpose is to read messages on some queues and pass on to some other thread – sri Dec 19 '12 at 12:22
  • 1
    @AdriC.S.: In theory yes, as map::find is O(log(N)) whereas finding in an unsorted vector would be O(N). In reality though if the size of the thread-objects is small enough you get the extrem benefit of caching which will make the vector faster than one would expect based on the O(..)-notation. Stroustrup recently compared std::list and std::vector in one of his recent talks that exemplifies why vector is most of the time the container you want to use.. – MFH Dec 19 '12 at 12:23
  • @phresnel: In this case sri is creating 300 hundred threads. Since you suggested de `find_if` approach should I suppose that's better than the map?. – Adri C.S. Dec 19 '12 at 12:23
  • @MFH: Do you have a link to that talk or somewhere I can check it?. I'm interested in what Stroustrup said. – Adri C.S. Dec 19 '12 at 12:25
  • 1
    @AdriC.S.: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style – Zeta Dec 19 '12 at 12:28
  • 1
    @AdriC.S.: Have a look: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style – MFH Dec 19 '12 at 12:28
  • 1
    @AdriC.S.: `find_if` is a standard library algorithm in C++ which works with any container. Whether a `map` or a `vector` or any other structure is optimal depends not only on the size of the container, but also on access patterns. In the end only real world test-runs can show you what performs better. – Sebastian Mach Dec 19 '12 at 12:34