RE: [boost] Re: Threads docs updated in CVS

From: Asger Alstrup Nielsen (alstrup_at_[hidden])
Date: 2001-08-09 07:02:21

> pthread C _join is *NOT* equal to win32 Wait... what it does
> in terms of win32 API is the following:

Just because the Win32 has a Wait, the Boost.Threads does not have to
have the same semantics.

> 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. I don't understand the join concept at all
except that it seems like another name for wait_for_exit: The current
thread waits until another thread exits. 
Whether or not more threads can do this at the same time, does not imply
that the name should be different. I have no problem imagining many
threads waiting for the same thing to happen. On the other hand, I have
a problem with many threads "joining" at the same time.

Maybe you are arguing that "join" is a common technical term that exists
because it is not as simple as "wait_for_exit". Is it so that in the
case where several threads are waiting on the same thread to exit, one
calling thread will be treated differently in some way? 
If so, this is surprising, and this does provide a good reason to use a
technical term. However I have never met this technical term before, and
therefore it obviously fails to bring this difference to my attention.
Also, the documentation does not mention such a difference (which of
course might be because the situation can not occur in the current
Boost.Thread system. And then there is no good reason not to use
wait_for_exit.)

One problem with join is that it implies symmetry, and we do not have
symmetry. If a change of state occurs because of this call, it will only
be the calling thread. This thread will then go into the blocked state,
which is defined as waiting for a resource. The documentation explicitly
says that blocked and waiting are synonymous terms. There is no
"joining" state, AFAIK.

I think the method should be named to make it as clear as possible what
it does. What pthreads, Java or win32 does is interesting to look at for
inspiration, but since Boost.Thread starts from scratch, it's only
natural to use the best names from a clean slate.

When I look up "join" in the Java documentation, it says "Waits for this
thread to die", and it does not warm against special behaviour. So why
use a different name than this?

With this background, I still think wait_for_exit is the best contender
since then there is one technical term less to understand.

Greets,

Asger