A function that do an asynchronized job

Question

I have function foo:

void foo(){
    //Command set A
    std::this_thread::sleep_for(100s);
    //Command set B
}

The first part which is Command set A has to block the execution. However, the sleep part and //Command set B does not have to block the execution and does not return any data.

So I implement it as follow:

void foo(){
    //Command set A
    std::thread t([](){
        std::this_thread::sleep_for(100s);
        //Command set B
    }
    t.detach()
}

Did I utilizedetach correctly here? Is it the right place to use detach? is there a better solution?

I'd say detach is correct as long as you don't care about any output from command set B (like if it fails). If you joined, it would block. — vincent, Jan 07 '18 at 18:45
When exiting the program you better make sure there are no other threads running anymore. I don't see how you would do that in your current implementation. — nwp, Jan 07 '18 at 18:55
Personally, I would say never use `detach` unless you have put in place mechanisms to control the thread's demise. — Galik, Jan 07 '18 at 18:56
@nwp So, in other words, detach as a concept is not recommended? — Humam Helfawi, Jan 07 '18 at 18:56
@Galik Actually my question is a bit hypothesis. I solved my problem in another way. But I was wondering if detach was created for such case or not. So, I asked. — Humam Helfawi, Jan 07 '18 at 18:57
@nwp If `Command set B` does not need to access any data from the main program/thread it should be ok? — super, Jan 07 '18 at 18:59
Generally no. Sometimes your process never terminates and sometimes you implement joining via [`set_value_at_thread_exit`](http://en.cppreference.com/w/cpp/thread/promise/set_value_at_thread_exit), but generally you don't need that. — nwp, Jan 07 '18 at 19:00
It is not recommended in general because you can't control the thread without adding other elements for that purpose. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rconc-detached_thread — Galik, Jan 07 '18 at 19:00
@super [No, it's not ok](https://stackoverflow.com/questions/19744250/what-happens-to-a-detached-thread-when-main-exits). — nwp, Jan 07 '18 at 19:02

score 6 · Accepted Answer · answered Jan 07 '18 at 19:22

detach is rarely the correct solution. If does exactly what it says: It removes the connection between the std::thread object and the actual thread. The thread keeps running until it finishes on its own, but your program has lost any control over it, if you don’t explicitly implement communication with the thread (e.g. via a message queue).

Things become problematic if the threads is still active when your program ends. Your process is in the middle of releasing its resources and dying, but the thread is chucking merrily along, using some of these resources. Because all resources are released, even the most basic ones (think low-level C++ runtime) that’s a recipe for desaster. Chances are, your program will crash on exit.

Look into std::async for a straight forward replacement. It runs a task asynchronously and immediately returns a std::future. Even if the task doesn’t return any data then the future is the handle you can hold on to and on program exit check if the thread is still running – and wait for it to finish, if necessary.

A function that do an asynchronized job

1 Answers1