Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-30 09:24:42

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> 
> > Well, you and others have convinced me that ref-counting is a 
price
> > one shouldn't have to pay if they don't need it.
> 
> I have to repeat my question to Gary. In what real world situations 
is the
> overhead of thread::ref unacceptable? [Note that thread::ref doesn't
> necessarily mean reference counting; other implementations are 
possible;
> even a reference counted implementation can be made more efficient 
than
> shared_ptr because it can use intrusive counting and custom 
allocation.]

When does a virtual method ever lead to real world time issues?  It 
does, and the C++ language is designed according to this fact, even 
though it may be difficult to give a precise example for when this 
may be true.  C++ is a "too the metal" language design, and I think 
we should try to honor this in our own design.

> > If ref-counting is
> > needed a second layer can be created, or more than likely
> > shared_ptr<> can just be employed.
> 
> True. However, if the noncopyable thread object is never useful on 
its own,
> without this second layer, then leaving the management to the 
implementation
> (via thread::ref) is a good thing, since it enables implementors to 
use
> platform-specific optimizations.

The non-copyable object *is* useful on it's own.  So far all of the 
examples in the Boost.Threads library can be done with a non-copyable 
design (though the examples that use loops will require creation on 
the heap, but this doesn't mean ref-counting).
 
> > Personally, I'm not settled on any of the three designs so far.  I
> > was leaning towards the ref-counted design only because of the 
self()
> > problem.  Since this third design addresses this issue, I'm not
> > convinced that the overhead of ref-counting is a good idea.  Since
> > the native types aren't ref-counted (Win32 threads are, but 
they're
> > rarely used that way, so I'll make this claim any way) I conclude
> > that you rarely need the overhead of ref-counting and think we 
should
> > avoid it if we can.
> 
> True, in principle; but avoiding the 'overhead of reference 
counting' only
> means shifting this burden to users.

Yes, but again this is in keeping with C++ design.  As long as the 
burden is minimal (it is) then I say go with the more "too the metal" 
design.
 
> > (In case I confused anyone by first arguing that programmers 
copied
> > these things frequently and so we needed ref-counting to now 
claiming
> > the native types aren't ref-counted, the trick is that the native
> > types are _copyable_ in the exact same sense as pointers.  The
> > programmer has to decide which copy to use for actual ownership.
> > There's no ref-counting done.  We could go with a design like 
this as
> > well, but it's less safe than any of the others.)
> 
> A thread::ref can use the fact that the underlying native type is
> lightweight and copyable for further optimizations (sometimes 
avoiding heap
> allocation altogether); in fact I think that a good implementation 
of
> thread::ref need not introduce any noticeable overhead.

Nope.  Just like a raw pointer, actual ownership is going to have to 
be tracked.  There's not any way to take advantage of the fast copy 
semantics of the native types.

> [For instance, a thread::ref can store the native type and one/two
> thread::ref pointers, using the 'linked shared pointer' idiom.]

This is only a variation on ref-counting.  Yes, we can optimize the 
management of references, but we simply can't eliminate the overhead.

Bill Kempf