Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-07-01 08:02:08

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> > > At 11:41 AM 6/30/2001, Jeremy Siek wrote:
> > > 
> > >  >On Sat, 30 Jun 2001, Peter Dimov wrote:
> > >  >> Creation on the heap is orders of magnitude more expensive 
than managing
> > >  >a reference count.
> > >  >>
> > >  >> This is the major problem I see with a noncopyable design. 
[This is not
> > >  >> limited to the current discussion, but applies in general.] 
The design
> > >  >> forces the user to use 'new,' a keyword that has no place 
in user land.
> > >  >
> > >  >I agree strongly with this. The design should not force the 
user to call
> > >  >'new'. I'd much rather see a copyable thread_id type.
> > > 
> > > I've also come around to that view.  We may now all be arguing 
violently 
> > > about something we all agree on.
> > 
> > Well, I don't agree with it ;).  However, it seems like I've 
become a 
> > minority of one, and since my own initial design used ref-
counting...
> 
> No, your not alone.  Gary and I remain concerned that the 
thread::ref
> implementation might have unacceptable overheads in some cases.  But
> I am myself even more concerned about being able to safely manage 
the
> lifetime of the references, and Peter is convinced that clever 
enough
> implementations of thread::ref will be plenty cheap enough.  If 
Peter
> is wrong and Gary is right then I vote for the (slightly redundant)
> two layer design.

I still see no way to make the management insignificant, especially 
if you consider the addition of a v-table significant, since this 
management is almost certainly going to be more expensive since it 
must be thread safe.

> > I'll stop arguing now.  Give me a few days and I'll have an 
> > implementation using thread::ref.
> 
> I know it's frustrating, but it's important to get this right.

I know it's important to get this right.  Unfortunately, there's no 
way to prove one design right over another with out extensive 
experience, which we can't really gain.  Since most people are 
convinced that the thread ref approach is the better way to go with 
out the experience, I'm willing to go that route.
 
> Perhaps we should just put implementations of the leading two or
> three interfaces in the vault and let people get more experience
> with the alternatives.

Not a bad suggestion... however, I'm not sure how much experience 
people will gain.  I'm not sure it'll be enough to really determine 
anything.  What would be better is to do some timings on the thread 
ref approach... but with out an optimal scheme for managing the 
references the timings are pointless.  And I simply don't see how 
Peter's going to optimize this.
 
> I'll be incommunicado for the next two weeks, so with any luck this
> will all be worked out when I return ;->

Well, I expect there'll be a Boost.Threads submission within that 
time frame, so it depends on what you mean by "worked out".  Someone 
could complain during the submission process that we chose the wrong 
design ;).

Bill Kempf