Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-30 08:25:02

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 09:15 AM 6/29/2001, williamkempf_at_h... 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):)

It's probably just my own absence that's caused confusion.

> 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.

Well, you and others have convinced me that ref-counting is a price 
one shouldn't have to pay if they don't need it.  If ref-counting is 
needed a second layer can be created, or more than likely 
shared_ptr<> can just be employed.  Creating threads in a loop is 
still going to be a tad more inconvenient than what some are used to, 
but any C++ programmer should be able to adapt to the other style.  
In fact, with the simple addition of a "thread_group" concept the 
loop problem shall become trivial, even if different from what 
programmers are used to.
 
> 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.

Personally, I'm not settled on any of the three designs so far.  I 
was leaning towards the ref-counted design only because of the self() 
problem.  Since this third design addresses this issue, I'm not 
convinced that the overhead of ref-counting is a good idea.  Since 
the native types aren't ref-counted (Win32 threads are, but they're 
rarely used that way, so I'll make this claim any way) I conclude 
that you rarely need the overhead of ref-counting and think we should 
avoid it if we can.

(In case I confused anyone by first arguing that programmers copied 
these things frequently and so we needed ref-counting to now claiming 
the native types aren't ref-counted, the trick is that the native 
types are _copyable_ in the exact same sense as pointers.  The 
programmer has to decide which copy to use for actual ownership.  
There's no ref-counting done.  We could go with a design like this as 
well, but it's less safe than any of the others.)

Bill Kempf