Very careful indeed! Thanks for making the valid points:
Well, I am not sure about threads that hang/deadlock; IMO,
that is a clear sign of an error in the synchronization
scheme. Of course you can explicitly program your threads to
hang, however, if they do it by themselves, that's another
story...
Yes. I was pressed for time when I wrote that, and didn't
formulate it really well. Basically, the problem I was
worrying about was along the lines of:
start_thread_which_does_very_long_calculations() ;
do_something_in_parallel() ;
join_with_child_thread() ;
My issue is what happens if somewhere in
do_something_in_parallel(), an exception is raised. If you put
the join in a scope guard, then you block the propagation of the
error until the child thread has finished. While I certainly
wouldn't use exceptions to propagate an error which must be
handled in hard real time, somehow, blocking propagation for,
say 15 minutes, or an hour, or whatever, doesn't appeal to me
either.
The problem isn't necessarily so much that the thread really
hangs, in the absolute sense, but that it continues as if
nothing were wrong, and the parent thread rests blocks until it
finishes.
This is also one of the things I don't like about boost threads.
If you're using boost::threads in the above scenario, the
exception is propagated, because boost::thread will detach the
child thread. But the child thread continues working, possibly
taking up resources, etc. And of course, you can't do a clean
shutdown as long as a thread is running, and because the thread
has been detached, and because it wasn't designed to be used as
a detached thread, you probably have no way of knowing whether
it is still running or not.
I think your talking about joining threads that you did not
program (e.g., joining a thread created be a third-party
library). Alls you can do is cross your fingers and hope that
the designers of the library knew what there were doing.
Which is rarely the case. I've more or less given up on clean
shutdown when third party libraries use threads. I just design
my application so that "kill -9" won't ever leave corrupt data,
and count on the OS to clean up everything else. (I have to do
this anyway: if the program can survive a power failure in the
middle of a critical disk write---and it can---then "kill -9" is
no problem either.)
My comments were meant more to address the issues that you have
to consider when you master both threads. The original posting
seemed to suggest that scope guard could handle the join without
any other considerations, which is very naïve. (A scope guard
which behaves differently according to whether you've committed
or not might be useful in some cases, however.) The actual
issues are very complex, and far beyond what I can really
explain in a simple posting; I was only trying to hint at some
of the problems that you need to address. While not your case,
I have the impression that a lot of people fail to think of
these things.
.