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

From: williamkempf_at_[hidden]
Date: 2001-06-22 08:48:40

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

Such an idiom would be a hardship in C++ with out a GC.  I've also 
seen many Java thread derived classes that call start() in their 
constructors... which to me shows how awkward the two phased 
construction is, even in Java.

> But it is also not unknown to create a fixed size pool of Thread
> objects, and then start them later on demand.

I'm curious as to why.  This just doesn't seem like the best solution 
to any problem.
 
> > > > > 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.

I'm more interested in the interface as well, but this is the first 
anyone's commented on it ;).  The name may well be important here, 
however.  I understand Beman's argument and so I'm open to a name 
change here... but a change to thread_handle, thread_id or 
thread_desc, for instance, would necessitate a change to the 
interface as well.  Some of the static methods make sense when the 
class is named "thread", but not when any of these others are 
chosen.  The static methods sleep(), yield() and even create() and 
self() are not actions one would expect to take on a 
handle/id/descriptor to a thread, but are actions you'd expect to 
take on the thread itself.
   
> > > > > 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.

Sounds like you're familiar with non-preemptive threads then.  I'd be 
very intersted to here from you about areas in which you think the 
interface will cause problems for this style of threading, or where 
other methods may need to be added to support this.

Bill Kempf