Re: [boost] Re: Boost.Threads - name of the "thread" type

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-21 17:49:37

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...>
> > > > Must constructing a thread automatically start it running?  Why
> > > > not a separate start() member?
> > > 
> > > In general, I've never cared for this approach.  Why have a two 
> > > phased construction?
> > 
> > It can be nice to first set up bunch of threads and then start them.
> 
> In general this isn't a common need.  Why must a group of threads be 
> started at the same (or nearly same) time?  If they are properly 
> parallel processes they shouldn't have a need for this.  If you 
> really have a need for this it would be nearly as easy to explicitly 
> code for it using a condition variable instead of having this 
> functionality built into the library.

OK.  In java the idiom  (new MyThread()).start() is pretty common.
But it is also not unknown to create a fixed size pool of Thread
objects, and then start them later on demand.

> > > > Must destroying a thread object stop thread execution?  How?  Note
> > > > that java was forced to deprecate it's Thread.stop() method in
> > > > favor of Thread.interrupt(), which just throws an exception on
> > > > the thread.
> > > 
> > > Actually, I have no plans at this time to support thread cancellation 
> > > (to use terminology more familiar to most folks here).  Thread 
> > > cancellation is a slippery slope in C++ for reasons beyond just those 
> > > discovered in Java.
> > 
> > Then if ~thread() doesn't stop execution, and the thread* isn't
> > needed by the threadfunc, I don't see why not to allow thread
> > objects to be constructed wherever, and even be copied.
> 
> The crux of it is that a "thread" is an execution state, which 
> obviously can't be copied.  The thread _class_, however, is nothing 
> more than an id, handle, pointer, reference or some other concept 
> associated with the actual thread.  Beman thinks this makes the name 
> a poor choice.  (Beman, feel free to explain this better than I just 
> did... with out the full off line thread I'm sure I've left something 
> important out for others to grasp your argument properly.)

OK.  I'm much more interested in the interface than in the name,
but I see the point now.  I'd prefer a copyable object so that
users are not forced to traffic in raw pointers.
  
> > > > Is yield() intended to allow non-premptive implementations?
> > > 
> > > No.  In premptive implementations it's often useful to relinquish a 
> > > threads current timeslice early in order to allow other threads 
> > > access to a CPU earlier.  This is nothing more than a performance 
> > > optimization, but it's an important one.  On many systems a yield() 
> > > is equivalent to a sleep() of zero duration.
> > 
> > I think for standardization purposes it would be a good thing to
> > allow non-preemprive implementations, as does java.
> 
> I'm open to this, but I don't have the experience or knowledge to 
> address it.  I'll have to leave this up to others to handle.

Our java VM provides only non-preemptive threads, which has caused
surprisingly few complaints from customers.  They are not too hard
to implement with some variation on setjmp() and longjmp(), even on
systems that provide no real thread support.  Though I must admit
that I am debugging a hang in the scheduler as I write.