2

The standard library provides a mutex class, with the ability to manually lock and unlock it:

std::mutex m;
m.lock();
// ...
m.unlock();

However, the library apparently also recognizes that a common case is just to lock the mutex at some point, and unlock it when leaving a block. For this it provides std::lock_guard and std::unique_lock:

std::mutex m;
std::lock_guard<std::mutex> lock(m);
// ...

// Automatic unlock

I think a fairly common pattern for threads, is to create one (either as a stack variable, or a member), then join it before destructing it:

std::thread t(foo);
// ...
t.join();

It seems easy to write a thread_guard, which would take a thread (or a sequence of threads), and would just call join on its own destruction:

std::thread t(foo);
thread_guard<std::thread> g(t);
// ...
// Join automatically

  1. Is there a standard-library class like it?

  2. If not, is there some reason to avoid this?

Community
  • 1
  • 1
Ami Tavory
  • 74,578
  • 11
  • 141
  • 185
  • You could always detach the thread, and it would be "joined" (not really joined, but the same cleanup of resources would happen) automatically when the thread ends. – Some programmer dude Sep 08 '16 at 12:50
  • @JoachimPileborg Thanks. Detaching does something different, though, no? If you `join` (directly, indirectly) before leaving a block, you know that, once the block exited, the thread had finished. – Ami Tavory Sep 08 '16 at 12:52
  • `joining_thread` was recently proposed but [shot down](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0379r0.html). – T.C. Sep 08 '16 at 21:09
  • @T.C. Very interesting! Thanks – Ami Tavory Sep 09 '16 at 05:35

1 Answers1

4

This issue is discussed in Scott Meyer's book "Modern Effective c++"

The problem is that if there would be another default behavior (detach or join) would cause hard to find errors in case you forget that there is a implicit operation. So the actual default behavior on destruction is asserting if not explicitly joined or detached. And no "Guard" class is there also because of that reason.

If you always want to join it's safe to write such a class yourself. But when someone uses it and wants to detach people can forget that the destructor will implicitly join it. So that's the risk in writing such function.

As an alternative you can use a scope_guard by boost or the folly library (which I personally prefer more) and declare in the beginning explicitly your intention and it will be executed. Or you can write a policy based "Guard" class where you have to explicitly state what you want to do on destruction.

Hayt
  • 5,210
  • 30
  • 37