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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-27 17:59:01

From: <williamkempf_at_[hidden]>
> --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > From: <williamkempf_at_h...>
> > > --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > > > From: <williamkempf_at_h...>
> > > ...
> > > > How important it is that Gary not pay for (possible) reference
> > > > counting he doesn't need I don't know, so I'll leave it to
> > > > Gary to actually argue for one of these if he wants.  I remain
> > > > satisfied with interface 2.
> > > 
> > > These are all syntactic variations on one design (as you know), and 
> > > the key to focus on here is the syntax using the shared_ptr.   This 
> > > gives us creation syntax like this:
> > > 
> > > shared_ptr<thread> p(thread::create(proc));
> > > 
> > > This is nearly identical to the more intuitive syntax:
> > > 
> > > shared_ptr<thread> p(new thread(proc));
> > 
> > But it isn't identical, because the shared_ptr returned by
> > create() would have a count of two, not one, which count is
> > decremented when the thread function returns.
> >
> > Well, a small benefit anyway.  It's not my favorite design.
> > 
> > > To me the decision comes down to a simple question.  Do we need a self
> > > () method?  If we do, we must go with "Interface 2" since it's the 
> > > only one that will allow for a self() method.  If we don't, we 
> should 
> > > probably opt for "Interface 1" since it's conceptually a cleaner 
> C++ 
> > > design and easily allows for ref-counted usage through the above 
> > > syntax with no modifications to the interface.
> > 
> > No, it doesn't easily allow for ref-counted usage.  Or else
> > I'm missing something.  Perhaps you are assuming that ~thread()
> > does a detach(), so the extra count is uneeded?  And you are
> > assuming that shared_ptr will be made thread-safe soon enough?
> 
> Yes.
>  
> > And that we can get by without self()?
>
> I don't understand what you're asking here.  Please elaborate and I'd 
> gladly answer.

If the thread object can go away while the thread is still
running then what will self() do?  Thus my thought that an
extra increment is needed in the create function and with
a balancing decrement (and possible delete) at the return
from the thread function.

> > And that the Windows implementation of thread::ref would need
> > to use explicit reference counting anyway, rather than the
> > (possibly) more efficient DuplicateHandle?
> 
> The original implementation required more state than just the 
> HANDLE.  I'm not sure a new implementation with the latest interfaces 
> would, but regardless you've dropped down into implementation details 
> and are looking at optimizations... two things we shouldn't do while 
> discussing the interfaces (unless the implementation details make an 
> interface prohibitive).

Well, Gary was concerned that the thread:ref interface would
impose enough overhead as to require a separate thread class.
I'm not so concerned, but willing to be convinced.  It might
be an issue in tight embedded systems.

Also, I think we have scoped the domain of possible interfaces
well enough that efficiency becomes a reasonable criteria for
choosing between them, ceteris paribus.  My feeling is that
the overhead for thread::ref is manageable, but that I prefer
to keep the possible reference counting an implementation
detail so as to allow for optimal implementations on all
platforms.  The counter argument is that the uncopyable thread
class can have the lowest possible overhead, and if you need
to copy you can pay the price.