From: williamkempf_at_[hidden]
Date: 2001-06-29 08:15:46
I have a wedding to attend today so I wasn't around yesterday and
won't be around again until monday. However, I had a thought about
the design that I'd like to share (hopefully no one else has posted
the same thought... I've not caught up on the thread yet). There's a
third design which I think solves most of the problems and leaves us
with a design that I think is pretty consistent with C++ design.
class thread : noncopyable
{
public:
// Constructs a thread object for the currently running
// thread of execution. A form of the self() method
// that I thought would be needed and would make Design 1
// impossible.
thread();
// Constructs a thread object for a new thread of execution
// that runs threadproc().
thread(boost::function0<void> threadproc);
// Cleans up any appropriate state information.
~thread();
// Checks for equality between thread objects.
bool operator==(const thread& other) const;
bool operator!=(const thread& other) const;
// Polls to see if the thread is still running.
bool is_alive() const;
// Blocks until the thread is no longer running.
void join();
// Causes the current thread of execution to block
// for a period of time.
static void sleep(const xtime& xt);
// Relinquishes a thread's current time slice on
// preemptive implementations and allows another
// thread to run on non-preemptive implementations.
static void yield();
};
This design appears to be an easier design to implement, is more in
line with other C++ designs and doesn't suffer from some of the
problems pointed out about the other two designs. The only thing I
see as possibly wrong is that there's not exactly a one-to-one
relationship between the class and the thread of execution. In other
words there can be multiple thread objects for a single thread of
execution. I don't think this is wrong as far as the design is
concerned, but it does lead back to a question about the name.
Personally, I find calling this class design a "thread" is less
confusing than the original since you can't directly copy thread
objects, but technically it's still suffering from the same problem
as Beman originally pointed out. Thoughts?
Bill Kempf