Re: Boost.Threads - thread_desc concept

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