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