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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-01 10:55:30

From: <williamkempf_at_[hidden]>

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

Why? It's simple: if a generic thing is better than your custom thing, you
are free to simply typedef your custom thing to the generic thing.

So the generic thing can never win. It can only break even.

> > Of course I expect better performance. The implementation is free to
> > optimize, or remove, the allocation.
>
> *If* it's even possible.

I think that on Win32 a thread::ref can contain only a HANDLE (and a DWORD
if you insist on being able to compare thread::refs for equality - you can't
compare HANDLEs.)

If you think that this isn't possible, I'll be interested to hear the
reasons. Since you've been working on Boost.Threads (and I've not) it's
possible that I'm missing some critical point of the picture.

I don't see how you can come up with a more efficient noncopyable thread
than this. Again, it may be just me.

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

I don't follow your logic. thread::ref suffers - potentially! - from
overhead in construction and destruction and this is not acceptable;
explicit management techniques suffer from overhead at construction and
destruction since new/delete must be used BUT this is acceptable?

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

Hm. I said "if you are in the same building as the pthreads implementor"
meaning that you - the std::thread implementor - are in the same building
with the pthreads implementor.

Does this clarify my point?

--
Peter Dimov
Multi Media Ltd.