Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-02-13 17:04:57

Sean Kelly wrote:
> scott wrote:
>> very briefly, the boost model treats threads as a resource (fair
>> enough
>> to :-) and submits code fragments for asynchronous execution. in the
>> alternate model, threads come about as a consequence of instantiating
>> final (a la java) objects.
> This is how I've always dealt with threads. I think you can create
> the
> same effect with Boost threads if you really want to however:
> struct A {
> boost::thread* t;
> A() {
> t = new boost::thread( *this );
> }
> void operator()() { ... }
> };
> The only irritating thing is that Boost threads need to be passed the
> executing object on construction so you need to allocate it
> dynamically.
> I'll admit I do prefer the inheritance model in most cases. Perhaps a
> new class called thread_base could be added so both methods are
> available? It would be a pretty simple addition.

Did you have something like this in mind:

// untested code
class thread_base : noncopyable
    thread_base() : pThread_( new boost::thread( *this ) ) {}
    ~thread_base() { pThread_->join(); delete pThread_; }

    virtual void operator()() = 0;
    friend class boost::thread;

    boost::thread * pThread_;


If yes, how do you ensure that operator() is not called before the subclass
object is fully constructed? Moreover, when destructing the subclass object
we have the problem that the subclass portion of the thread object is
destructed before we call join() in the base class.
So, to make the thread_base safe, we have to do the following:

class thread_base : noncopyable
    ~thread_base() { delete pThread_; }

    void start() { pThread_ = new boost::thread( *this ); }
    void join() { pThread_->join(); }

    virtual void operator()() = 0;
    friend class boost::thread;

    boost::thread * pThread_;

And call start() in the subclass constructor and call join() in the subclass
destructor, what can be easily forgotten by someone deriving from
thread_base. I think this was one of the reasons why the design of
boost::thread did not go down this road...



Boost list run by bdawes at, gregod at, cpdaniel at, john at