Re: [boost] Re: Redesigned thread class

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-28 09:58:46

From: "William Kempf" <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> >2. (POSIX-based) current() works as intended provided that pthread_join()
> >and pthread_detach() are never called on an adopted thread.
>
> This is more than a tad confusing.  A "POSIX-based" current() *IS* a
"fully
> compliant" current, no matter what definition of "compliant" you want to
> choose.  The minor restriction added here that "pthread_join() and
> pthread_detach() are never called on an adopted thread" is, in practice,
> what most code does already.  This is the proposed semantic since it
> provides "fully compliant" adoption on both target platforms and is likely
> to allow "fully compliant" adoption on any other platform as well.  It's
the
> only one of the options you list that can do this.

(POSIX-based) refers to the fact that the implementation is POSIX-based.

Fully compliant current() means that it produces a reference to a
full-featured thread object, as if the thread has been created by the
library.

Your proposed semantics is #3 and not #2 since #2 implies that the thread
object that has been implicitly created when current() adopts a thread will
be either joined via pthread_join (by using thread::join) or detached via
pthread_detach in the destructor. This is why it's required that user code
does not call either pthread_join or pthread_detach on an adopted thread.

> >3. (POSIX-based) current() works as intended except that an adopted
thread
> >is not joinable; whoever created the thread is responsible for joining or
> >detaching it.
>
> This is identical to (2).

It is not. It is identical to your current semantics. An adopted thread is
not joinable, and the destructor does not detach.

> I beg to differ.  #2 is the very definition of the proposed Boost.Threads
> implementation (and again I see no difference between #2 and #3).  So long
> as the thread_ref design uses "wait" semantics instead of "join" semantics
> the implementation is identical whether done on top of Boost.Threads or
> POSIX threads (provided I lift the restriction on the "current" thread
> object being valid only within the current thread of execution, which I
said
> I could do if this were a show stopper).

I don't quite understand. Why should a thread_ref use "wait" semantics? As I
said, thread_ref join is exactly equivalent to boost::thread::join.

> I don't know, frankly.  In general I consider it to be a design flaw to
join
> the initial thread, so see no purpose in treating it any differently than
> any other adopted thread.

The difference is obvious. A fully compliant C++0x program (assuming that
C++0x has threads in the standard library) that doesn't use any pthread_* or
other native threading calls does not have any need to adopt threads, but it
does have a main thread.

--
Peter Dimov
Multi Media Ltd.