Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-21 16:19:16


From: <williamkempf_at_[hidden]>
> --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > From: <williamkempf_at_h...>
> > > ... Beman sugggests ...
> > > So in my mind, either change the class name to something that
> denotes
> > > identifier, handle, or the like, or change the semantics to be
> more
> > > thread-like and less thread_id like. Make it noncopyable, and
> so
> > > forth. I don't entirely see how to do that. I guess a
> create_thread
> > > static or free function could return a pointer to a thread
> object.
> > > Then delete of the pointer would kill the thread. But it would
> have to be
> > > a weak pointer because the thread might already be dead and thus
> the
> > > object already destroyed.
> > >
> > > class thread : noncopyable
> > > {
> > > // All constructors private, so thread::create()
> > > // is the only way to create a thread
> > > thread();
> > > ...
> > > public:
> > > ~thread(); // assert(*this != self())
> > >
> > > bool is_alive() const;
> > > void join();
> > >
> > > static thread * create(void (*threadfunc)(void*), void*
> > > param);
> > > static thread & self();
> > > static void join_all();
> > > static void sleep(const xtime& xt);
> > > static void yield();
> > > };
> >
> > I understand noncopyable, but why force heap allocation via the
> > create call?
> >
> > 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.

> > Is the ugly (void (*threadfunc)(void*), void* param) really needed?
> > Why not (void (*threadfunc) (thread*)), or even a virtual run()
> > method?
>
> Either approach requires derivation from a base "thread" class (in
> quotes because the name is truly what's being discussed here, despite
> this sideline). This adds complexity with out adding any real
> functionality, so I don't like either of these approaches. However,
> the signature will be changing very shortly to make use of
> Boost.Function.
>
> > 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.

> > What is the difference between join() and join_all()? Should they
> > take an optional timeout?
>
> Join waits on a thread while join_all waits on all currently
> executing threads. The join_all method is really just a
> convenience... one that may deserve seperate discussion on it's
> appropriateness. Along these lines I think it might also be worth
> discussing a thread_group concept similar to that in Java which would
> accomplish the same thing as join_all.
>
> As for time outs, I purposely left them out since not all threading
> libraries support them. However the current implementation shows
> that it would be trivial to include a timeout even on these
> platforms. If a real need is found for this I can add this with out
> breaking anything.
>
> > 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk