Re: [boost] Re: Boost.Threads - thread_desc concept

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
 >{
 >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?

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.

--Beman