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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-01 09:56:36

From: <williamkempf_at_[hidden]>

> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
[...]

> > I'm simply trying to explain that thread::ref _can_ conform to the
> > zero-overhead rule, whereas an explicitly reference-
> counted 'thread' cannot.
>
> I'd have to see an implementation that managed this.  I don't see how
> it could, especially since it must retain thread safety.

thread::ref will be, at worst, as efficient as
thread_safe_shared_ptr<thread>, right? If it's not you'll simply implement
it this way.

> However, I should point out that it's *very* likely that some
> implementations are going to need to do both memory allocation and
> ref-counting to implement a thread::ref concept.

Correct, but the important thing is to provide a specification that does not
preclude implementations to avoid the overhead as much as possible.

Using a generic thread-safe memory allocator and a generic thread-safe
reference counted smart pointer can never be more efficient than using
tailored versions.

> So instead you bury it in the implementation and expect better
> performance?

Of course I expect better performance. The implementation is free to
optimize, or remove, the allocation.

> I still don't see how to get a thread::ref with out overhead (and
> significant overhead at that).
[...]
> Destroying a non-unique thread::ref also involves overhead, and this
> is not necessarily insignificant.  Copying the thread ref also
> entails overhead, which again may not be insignificant.

This is not a fair comparison.

If you had a noncopyable design you could never copy nor destroy a
(non-unique) object, right? So thread::ref has no overhead _provided_ that
you use it like you would use a noncopyable object.

And thread::ref has no overhead compared to shared_ptr<thread> for reasons
already stated.

[ And if you are in the same building as the pthreads implementor for your
OS, you could do some truly amazing things with the thread::ref design. :-)
This is our long term goal, right? ]

--
Peter Dimov
Multi Media Ltd.