Re: boost::thread
On Aug 7, 11:18 am, James Kanze <james.ka...@gmail.com> wrote:
On Aug 1, 7:20 pm, Christopher <cp...@austin.rr.com> wrote:
class BaseThread
{
public:
BaseThread();
/// \brief Deconstructor
/// \detail It is required that a derived class make a call to
thread_.join()
/// in its deconstructor
virtual ~BaseThread();
virtual void Start();
virtual int Work() = 0;
protected:
void Run();
boost::thread thread_;
};
//---------------------------------------------------------------------=
------------------------------------------------------------------------
// BaseThread.cpp
#include "BaseThread.h"
//---------------------------------------------------------------------=
---------
BaseThread::BaseThread()
{
}
//---------------------------------------------------------------------=
---------
BaseThread::~BaseThread()
{
// Wait for the thread to complete
thread_.join();
I'm afraid I don't like this. I don't like the idea of a class
waiting for anything in its destructor; it can cause the code to
hang in unexpected places.
If the threads are to be joinable, then it is the client who
should do the joining, not the thread class. (But threads don't
have to be joinable.)
Silly question. I've heard this several times now, but I don't quite
see how you would do it otherwise. Let me give a simple example. I
wrote an alternative to std::for_each called concurrent_for_each. It
takes a range, a functor/function (like std::for_each), and an number
of threads (optional). It applies the functor/function to each element
of the range just like for_each, except it applies it in some
unspecified order, possibly concurrently.
Specifically, the idea is to split the range into sub-ranges and give
each sub-range to a throwaway thread. (If I was feeling especially
fancy, I could stash the threads instead of remaking them for each
concurrent_for_each invocation.)
Now, the question is how to write the function. The only sensible
approach seems to be to give the weak exception guarantee, that if an
exception is thrown by an invocation of the functor/function, then the
range will be left in some consistent state, but it's not specified
which state. It would be hard to give anything stronger while allowing
concurrent execution and modification of elements in the range.
So, the concurrent_for_each function is pretty simple. It's divide the
range into subranges, create the N threads with a private main-functor
that applies the argument functor to elements in the subrange.
The problem happens when and if one of them throws. Alternatively,
what if a thread creation throws due to out of memory, or various
other fail conditions. Should you join on threads already created? I
would think yes. This seems like good style and resource management to
not simple forget about them. I've had several bugs from analogous
situations where presumably short lived processes were not joined /
wait'ed. I figure similar arguments apply to threads.
So, I could do a manual try block and join on all created threads, or
I could use a vector-like container which will call delete on its
contained pointers. The second approach appears to be the nicer one,
but this contradicts the advice you just gave. At least, I think it
does.
What do you suggest? Where have I gone wrong?