Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
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 
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.

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

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

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 
reasons
> 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 
for your
> OS, you could do some truly amazing things with the thread::ref 
design. :-)
> 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.

Bill Kempf