Date: 2001-07-01 10:31:28
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > I'm simply trying to explain that thread::ref _can_ conform to
> > > zero-overhead rule, whereas an explicitly reference-
> > counted 'thread' cannot.
> > I'd have to see an implementation that managed this. I don't see
> > 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
> it this way.
Yes, but we won't always need to use thread_safe_shared_ptr<thread>,
eliminating all of the overhead.
> > 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
> preclude implementations to avoid the overhead as much as possible.
> Using a generic thread-safe memory allocator and a generic thread-
> reference counted smart pointer can never be more efficient than
> tailored versions.
I'm not so sure about that.
> > 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.
*If* it's even possible. However, I'm not convinced that even if it
can be done that you can't get similar performance from a
shared_ptr<> concept. Further, all of this still assumes a need for
referencing at all. A 2 layered design does not suffer from this
> > 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
> > 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
> you use it like you would use a noncopyable object.
It still has overhead, you're just claiming the overhead is dwarfed
by the overhead of thread creation and destruction, which from a high
level view is at least some what accurate. However, with a
noncopyable design you can use explicit management techniques which
will always be *MUCH* more efficient than any ref implementation.
Yes, this suffers from overhead at construction and destruction since
new/delete must be used, but as you point out this overhead will be
dwarfed by the cost of thread creation and destruction any way.
> And thread::ref has no overhead compared to shared_ptr<thread> for
> already stated.
Again, it's not _no_ overhead. I really dislike this claim.
> [ And if you are in the same building as the pthreads implementor
> OS, you could do some truly amazing things with the thread::ref
> This is our long term goal, right? ]
No. Our goals have nothing to do with pthreads. Now if you change
this to say C++ standard library implementor you get a little closer
to what you mean. However, ref implementations *STILL* have overhead
that can be eliminated for a large number of uses of this concept,
while a 2 layered design can give you the best of both worlds.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk