0

I have a strange problem with Boost 1.54 threads which seem to block when the thread object goes out of scope.

Background: I'm working on a real-time application that uses external hardware through API calls. Some of these API calls block until execution. That's why I want to call them in separate threads in order to avoid blocking my main thread. The simplified structure looks as follows:

void some_func(){
    //t2
    boost::thread t(&blocking_call);
    //t3
}

int main(){
    //t1
    some_func();
    //t4
    return 0;
}

Luckily, the external hardware has an onboard clock so that I was able to time the execution of my program precisely.

What I observed: t1, t2 and t3 are - as expected - incrementing only a tiny little bit, but t4 is always shortly after the execution time of the API call which is a lot later (and unfortunately even too late for me). It seems as if the thread object was calling join() when it is going out of scope, although I thought it should just get detached and finish its work.

Any hints what might be the issue?

fewu
  • 229
  • 1
  • 10
  • 2
    Which `Boost` version? Recently they [changed behavior of thread destructor](http://www.boost.org/doc/libs/1_54_0/doc/html/thread/thread_management.html#thread.thread_management.thread.destructor). Try to call [`detach`](http://www.boost.org/doc/libs/1_54_0/doc/html/thread/thread_management.html#thread.thread_management.thread.detach) manually: `t.detach();` – Evgeny Panasyuk Oct 30 '13 at 14:49
  • 1.54, I added it above – fewu Oct 30 '13 at 14:58
  • I'm wondering if `boost::thread` automatically tries joining on it's destructor for undetached threads. – πάντα ῥεῖ Oct 30 '13 at 15:33
  • @g-makulik see the [following answer](http://stackoverflow.com/questions/11393936/breaking-changes-in-boost-thread-3-0-0/11394992#11394992) – Igor R. Oct 30 '13 at 17:42
  • @IgorR. Yes, that explains the behavior well. – πάντα ῥεῖ Oct 30 '13 at 17:46
  • After some more debugging it became clear that my external hardware causes the blocking in some (weird) way. Replacing the blocking call with a simple sleep shows expected behaviour. But your comments helped me to narrow it down, so thank you ;) – fewu Oct 31 '13 at 07:54

0 Answers0