Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-15 20:23:08

--- In boost_at_y..., williamkempf_at_h... wrote:
> > 	But it's only a name: names are not unimportant,
> > but Bill's rationale seems reasonable: boost's join is enough like
> > POSIX join to use the same term, and it has one huge advantage,
> > which is that it is tiny. :-) [only four characters]
> 
> More in another post...

I promised and now here it is...

A few preliminaries.  I'm currently unable to respond as frequently 
as I have in the past.  I'm not ignoring posts and will try to 
respond when possible, but that may be in a few days.  It also means 
that I may have some lengthy posts, like this one, to catch up with 
many arguments that are related but come from different posts.

Now, I've been discussing this with Beman in private e-mail as well.  
We brought up some important things that I wanted to cross post here, 
but now I think it may be better just to summarize, which I'll 
attempt to do here.  First, Beman suggested await_completion (among a 
few others) and if I do change the name, this is the one I like the 
best and will go with.  I'm open to changing the name, but I'm 
concerned that doing so is a mistake since both names are quite valid 
and reasonable.  So, no matter which I choose I expect I'll have made 
the wrong choice for a large group of people.

Let me try and list the pros and cons of both:

"join" pros:

* It's a well known industry term.
* It's the name used by nearly all of the thread libraries that I'm 
familiar with, among them POSIX, ACE, Java, J-Threads (obviously) and 
even the .NET Thread class (showing that even MS prefers this term).
* Because of the last two most people that have programmed threads in 
the past are familiar with the name, either because the library they 
use uses the name, or because literature they've read uses the name 
(that's the camp I fall into).
* The name conveys the meaning in a precise and efficient manner once 
you are familiar with the term, and many can deduce it's meaning with 
out needing a definition (I was able to the first time I saw it).

"join" cons:

* New programmers may not be able to figure out what it means with 
out looking up a definition.  (This may be considered a good thing as 
well, though).
* Some may construe "thrd.join()" to mean that we're doing some sort 
of jump.  (I personally don't see this, this was an argument from 
someone else, but I accept that they may be right.)

"await_completion" pros:

* Easily understandable.

"await_completion" cons:

* New users aren't introduced to the term "join" at all, so when they 
read literature on MT (something they'd better do a lot of anyway!) 
they will likely have to contend with learning the meaning any way.

Someone pointed out that we chose to go with "notify_one" 
and "notify_all" instead of "signal" and "broadcast".  I was actually 
in favor of the latter initially, but enough people felt the other 
names were more meaningful and I was swayed.  Why am I not swayed 
this time?  Because "signal" and "broadcast" aren't as universally 
accepted as "join" is.

I'm willing to change the name, but I want to ensure (as much as 
possible) that enough people truly feel that "join" is a bad choice 
given the above, and that most of the other people can simply live 
with the choice.  If I feel the opinion here is polarized, like it 
currently seems to be, I'm going to err on the side of the accepted 
terminology and be done with it.

Bill Kempf