Re: Redesigned thread class

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-28 12:57:39

From: "Peter Dimov" <pdimov_at_[hidden]>
>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.

This just further confuses things for me.  I thought you were laying out 5 
different design approaches.  There will never be such a thing as 
"POSIX-based" the way you refer to it here, since Boost.Threads is portable.

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

Options #2 and #3 produce "fully compliant current()" by this definition.  
OK, to be fair you're referring to the restriction on not being able to 
"join" such objects, but I do not consider this to be as severe as you seem 
to.  A thread can be "joined" only once, the same as memory can be deleted 
only once.  Everyone's life (the implementer's as well as the user's) is 
made easier if you restrict current() threads in this way.  It also does not 
impact the implementation of a thread_ref in any way that doesn't currently 
exist for POSIX thread implementations any way.

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

OK, I misunderstood what you meant in your description of #2.  #2 is 
pointless and basically impossible to do.  Adopted threads will always be 
"joined" or "detached" by "user code".  There will be no threads to adopt 
unless code outside of the application's control (i.e. libraries) creates 
the threads, and this code is practically gauranteed to be in control of 
"joining" or "detaching" the thread.  Only in *extremely* rare cases where 
library code creates a thread but passes control to "user code" will #2 even 
be possible.  This one doesn't even deserve consideration.

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

That's an implementation impossibility for "adopted" threads.  For threads 
that were not adopted you can give true "join" semantics, but this is true 
for both POSIX and Boost.Threads base implementations for a thread_ref 
concept.  Now, once standardized it will be theoretically possible for 
implementations to give true "join" semantics even for adopted threads since 
the implementations can take advantage of platform details that we do not 
have access to in POSIX (and that's already the norm in Win32).  But at this 
stage we're strictly talking about implementations based on top of POSIX and 
Win32 constructs, and it's simply not possible to create a thread_ref with 
"join" semantics on top of POSIX.

Now, a valid decision would be to use "join" semantics for any thread 
created by the library and "wait" semantics for those that are adopted.  I 
see only a few small holes in doing this, and they are not likely to be real 
issues for any actual uses.  This is the route I'd go, and the Boost.Threads 
proposed design does not hinder you from doing this.

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

I've got two comments about this.  First, Boost.Threads isn't a part of the 
language.  We have to make some decisions and choices that a standards 
endorsed library would not, simply because they can accomodate such things 
with changes to the abstract machine.  The goal of Boost.Threads is to 
document such areas with the hope that the standards committee can address 
the abstract machine issues and change the library requirements accordingly. 
  In other words, Boost.Threads is not likely to allow "joining" of the 
"initial thread", but I'd expect the standard to more appropriately address 
this issue.

Second, even a standards endorsed library implementation is going to have to 
address the issue of thread adoption (though, like Boost.Threads, the 
standard should leave this as implementation defined).  There's simply a 
need to interface to legacy code and libraries.

Bill Kempf

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp