From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-01 09:56:36
> --- 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
> So instead you bury it in the implementation and expect better
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
[ 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk