Re: Threads docs updated in CVS

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-16 12:04:00

> From:  "Alexander Terekhov" <terekhov_at_d...>
[...]
> i have suggested to provide an
> option/functions which would allow to
> wait for both: [I-above] - less than
> posix "join" and [III-above] - equal
> to posix "join" (default), separately..
> i have also suggested that on destruction
> of not detached/"joinable" C++ thread
> (object), [III-above] should be done
> automatically.

a) news:nVNe7.183$bB1.17923_at_[hidden]

David Butenhof wrote:

"Originally, "detach" and "join" were separate operations.
 "Join" merely allowed a thread to wait until the target
 was complete. There was no reason that both threads 1
 and 2 couldn't wait for thread 3 to complete. But in
 order to ensure that system resources could be reclaimed,
 ONE (and only one) thread would then have to "detach"
 thread 3.

 In fact, nobody could ever construct a case where it made
 sense for both threads 1 and 2 to wait for thread 3 to
 complete. While there might be cases where thread 3 was
 doing something on which two threads depended, joining
 with it is never the right (or best) way to implement that
 dependency. (It really depends on some DATA or STATE, not
 on the completion of the thread, per se.) And it's silly
 to require two calls to "finalize" thread 3. Furthermore,
 one of the most common DCE thread programming errors
 was failure to detach after joining, resulting in a memory
 leak.

 So it was decided that join should implicitly detach the
 target thread once it was complete. In fact, the detach
 operation, and all reference to it, was removed from the
 standard. (Over the objections of some of us who knew
 better.)

 But there were two problems. There was no way to alter the
 initial thread of a process so that its resources would be
 automatically reclaimed on termination. And there was this
 nasty problem in join; where, if the join is cancelled,
 which implies it didn't complete, the target thread of the
 join would languish forever -- another memory leak about
 which the program could do nothing.

 The solution, of course, was to restore the detach operation;
 even though it was now less useful (and more rarely needed)
 than before.

 However, although the standard could now talk about detach,
 the description of join wasn't edited to make as clear as we
 might wish that, effectively, the join operation is "wait for
 termination and then detach". The standard says and implies
 in several places that one EITHER detaches OR joins, and
 only this discussion of the cancellation behavior of join
 suggests a connection or dependency."

b) so taking into account that "detach" applied to already
   terminated thread ("DCE-joined" thread) is nothing else
   but simply a request to reclaim resources (thread id/native
   thread object), i would strongly suggest that it should
   be done automatically on destruction of C++ thread object
   which refers to not detached/"joinable" thread (after
   waiting until the target is complete if it was not already
   done "manually" using some thread::XXXX method(s)).
   in the case of detached thread, C++ thread object should
   be destructed implicitly on thread termination (inside
   thread bootstrap routine or via tsd destruction mechanism)
   followed by a request to reclaim thread native resources
   (id/native object) using pthread_detach( pthread_self() );

regards,
alexander.