|
Boost : |
From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-09 07:52:53
> > in pthread only one thread could call _join and it could
> > do _join only ONCE. now, in terms of some C++ thread
> > library (e.g. Boost.Thread) it might become possibly to
> > call somethread.join() on multiple threads and continue to
> > do "join" calls as long as that C++ thread object exist
> > (C++ thread object would properly synchronize these calls
> > and would call native _join only once) nevertheless at
> > *one* would perform REAL join and others would
> > have to wait for it to occur. so, i believe that _join is
> > still a better name here even for C++ thread object which
> > could outlive "native" thread object <- get destroyed by
> > "first" (and the only one) native join call.
>
> Hmm, I don't understand this. Could you elaborate? I don't know what a
> REAL join or native join is.
on return from "REAL join or native join" the "joined" thread
(which *before the join* might have already terminated but not
yet been destroyed) does not exist anymore. destroyed.. gone..
completely! there is nothing to real/native-join with after that
thread has been destroyed. native/real join is a sort of "delete"
of internal thread objects. the alternative is to call "detach"..
which would first check whether that thread is still running
(has not terminated already):
a) if terminated then simply destroy it
(native join does the same);
b) if !terminated then mark it for auto/self-destruction
on thread termination;
another alternative is that you could simply create a
"detached" thread: { new DetachedThread(); }
the return value is rather useless (unless you have some extra
synch mechanism) because the thread might have already terminated
and have already been destroyed by the time "new"/pthread_create
returns.
regards,
alexander.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk