thread_guard vs scoped_thread

user_10664135 0
Viewed 970

In the book

"C++ Concurrency In Action" by Anthony Williams

you can find the following two snippet of code (I have introduced some slight modifications):

Snippet 1:

class thread_guard
{
    std::thread& t;
    public:
    explicit thread_guard(std::thread& t_): t(t_){}
    ~thread_guard()
    {
        if(t.joinable())
    {
        t.join();
    }
    }
    thread_guard(thread_guard const&)=delete;
    thread_guard& operator=(thread_guard const&)=delete;
};

void my_func()
{
    for(int j = 0; j < 1000; ++j)
    {
        cout << "\n " << j;
    }
}

void f()
{
    std::thread t1(my_func);
    thread_guard g(t1);
    do_something_in_current_thread();
}

int main()
{
    f();
    return 0;
}

Going on you can find

Snippet 2:

class scoped_thread
{
    std::thread t;
    public:
    explicit scoped_thread(std::thread t_):    t(std::move(t_))
    {
        if(!t.joinable())
        throw std::logic_error(“No thread”);
    }
    ~scoped_thread()
    {
        t.join();
    }
    scoped_thread(scoped_thread const&)=delete;
    scoped_thread& operator=(scoped_thread const&)=delete;
};

void my_func()
{
    for(int j = 0; j < 1000; ++j)
    {
        cout << "\n " << j;
    }
}

void f()
{
   scoped_thread st1(thread(my_func));

   thread t2(my_func);
   scoped_thread st2(move(t2));

   do_something_in_current_thread();
}

int main()
{
    f();
    return 0;
}

I'm not sure that I can really appreciate the real difference between these 2 snippets.

The only difference that I can see is that in Snippet 1 the instance of thread_guard does not take ownership of the thread t1 (unlike a scoped_thread object) and so it could be possible call t1.join() but this is not a problem when ~thread_guard() is executed.

So: where is (if exists) the advantage of Snippet 2?

c++14 c++11 multithreading c++
2 Answers

Both types are meant to block on destruction (e.g. scope exit) until a thread finishes. The difference is in the ownership of the thread object.

thread_guard doesn't own the thread itself; there may be more than one thread_guard waiting on the same thread. This also means that the thread object must be alive as long as any thread_guard refers to it. If the referenced thread has already been joined when a thread_guard object is destroyed, it won't block or produce an error (as opposed to just calling join on a thread that is not joinable).

scoped_thread, on the other hand, takes ownership of the thread instance, and therefore also controls its lifetime. You would use it whenever you want to own the thread you want to wait on, e.g. as a data member.

Ultimately, which one you use is a question of semantics: do you want to wait on a thread someone else owns (then you also have to make sure there are no lifetime issues), or do you want a thread object that blocks when it gets destroyed, without you having to join it first.

user_18497690

In terms of functionality these both implementation are capable to server the purpose, the only difference i can see in these two implementation is, Snippet 2 can accept both lvalue(glvalue) and rvalue(prvalue) but Snippet 1 can't accept rvalue(prvalue) as constructor argument. For example consider following code,

std::thread getThread()
{
    return std::thread([](){ std::cout<< __PRETTY_FUNCTION__<< std::endl;});
}

int main( int , char *[])
{
    thread_guard g( getThread());
    return 0;
}

Now if you compile this code, compile will give following error,

 error: cannot bind non-const lvalue reference of type ‘std::thread&’ to an rvalue of type ‘std::remove_reference<std::thread&>::type’ {aka ‘std::thread’}
     explicit thread_guard(std::thread _t): t(std::move( _t)){ std::cout<< __PRETTY_FUNCTION__<< std::endl;}

But snippet 2 implementation will work fine.

user_42622630
Related