From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-29 09:34:35
At 09:15 AM 6/29/2001, williamkempf_at_[hidden] wrote:
>.. 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
> // 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.
> // Constructs a thread object for a new thread of execution
> // that runs threadproc().
> thread(boost::function0<void> threadproc);
> // Cleans up any appropriate state information.
> // 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?
I think I must have lost the thread (of discussion):)
I see how the above addresses issues I was worried about, but not how it
addresses the usages like "create a bunch of threads in a loop and transfer
ownership elsewhere" you and others said were so common.
You, Greg, Peter, and others have done a pretty good job of convincing me
that the namespace thread containing a ref counted class was so useful and
so met the special lifetime requirements of threads of execution that it
should be adopted.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk