Re: [boost] Re: Boost.Threads - thread_desc concept

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-06-30 08:48:02

From: <williamkempf_at_[hidden]>

> 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.]

> 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.

> 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.

> (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.

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

--
Peter Dimov
Multi Media Ltd.