Boost logo

Boost :

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?
> > > > > not a separate start() member?
> > > >
> > > > In general, I've never cared for this approach. Why have a
> > > > phased construction?
> > >
> > > It can be nice to first set up bunch of threads and then start
> >
> > In general this isn't a common need. Why must a group of threads
> > 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
> > 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
> > > > > favor of Thread.interrupt(), which just throws an exception
> > > > > the thread.
> > > >
> > > > Actually, I have no plans at this time to support thread
> > > > (to use terminology more familiar to most folks here).
> > > > 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
> > more than an id, handle, pointer, reference or some other concept
> > associated with the actual thread. Beman thinks this makes the
> > a poor choice. (Beman, feel free to explain this better than I
> > did... with out the full off line thread I'm sure I've left
> > 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
> > > > access to a CPU earlier. This is nothing more than a
> > > > optimization, but it's an important one. On many systems a
> > > > 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at