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
> >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.
> > 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
> >line with other C++ designs and doesn't suffer from some of the
> >problems pointed out about the other two designs. The only thing
> >see as possibly wrong is that there's not exactly a one-to-one
> >relationship between the class and the thread of execution. In
> >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
> >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
> addresses the usages like "create a bunch of threads in a loop and
> 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
> that the namespace thread containing a ref counted class was so
> so met the special lifetime requirements of threads of execution
> 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.)
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk