Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-07-02 12:33:06

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> 
> > > You don't look convinced that a handle/body based design is 
easier
> > to use,
> > > though.
> >
> > I'm not.  The only example given by either of us that indicates 
more
> > ease of use is the example you just gave with a vector.
> 
> If you expand the examples that had a thread_manager or a 
thread_group in
> them, giving the full implementation, you'll see that they, too, 
demonstrate
> the same point.

No, they don't, actually.  Any difficulties in use (minimal) are 
eliminated by the other concepts.

> > However, we
> > deal with this all the time in C++ using a smart pointer, and the
> > ease of use with a smart pointer is nearly identical even if the
> > overhead becomes a wash again.  In fact, the thread ref concept is
> > just a variation on a smart pointer!
> 
> Of course it is! Call it whatever you like, a smart pointer, a 
handle, or a
> thread reference.
> 
> So, your unspoken question is probably "why provide a thread::ref 
when we
> already have shared_ptr?"

No, that's not really the issue.  Ref-counting is the exception, not 
the rule, to the need for lifetime management.  Explicit ownership is 
the norm, which is also much more efficient.
 
> Here's an example of creating a thread:
> 
> shared_ptr<thread> p(new thread(f));
> 
> This requires an explicit 'new', which several people have objected 
to. An
> easy way to eliminate the 'new' is:
> 
> shared_ptr<thread> p = thread::create(f);
> 
> This is better, but a custom thread-safe reference counted smart 
pointer
> may, under some conditions, outperform shared_ptr. (Plus, its 
operator==
> isn't exactly what you want.) So we get to:
> 
> thread::ref p = thread::create(f);
> 
> Now the only question left is whether we need the 
underlying 'thread' object
> or not. I've not been terribly successful in convincing people that 
it's, in
> fact, not needed - and sometimes harmful - so it will probably 
survive, much
> to my dissatisfaction. Such is life.

I'm not convinced that we need anything but the underlying type.  
Again, it's a rare idiom that needs ref-counting for lifetime 
management.

Bill Kempf