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