Date: 2001-09-25 07:58:35
--- In boost_at_y..., "Eric Friedman" <ebf_at_u...> wrote:
> --- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> > > As for changing the name... one name change request that's been
> > > several times that I've ignored I'd like to address one last
> > > The notify_one() and notify_all() methods on condition are more
> > > traditionally known as signal() and broadcast() respectively.
> > > persuaded to change them at one point, but I'm feeling like
> > > a mistake. I'm leaning towards changing them but I'll need to
> > > in the next day or two, so one final chance to argue this one.
> > >
> > notify_one and notify_all are more descriptive of what these
> methods do and
> > their relationship to each other. Those who are already familiar
> > signal and broadcast will almost certainly already understand the
> > functionality behind those names and should have little trouble
> equating new
> > names with concepts they already understand.
> > For those with less knowledge of the underlying concepts,
> descriptive names
> > will be beneficial, while historical names may not be. broadcast
> is not
> > bad, since it implies a potential one-to-many style of
> > However, I can't see how one could interpret signal to be a
> counterpart to
> > broadcast (historical uses aside)--the definition of signal does
> not imply a
> > one-to-one relationship between the signaller and the signalled.
> I agree entirely with Scott on this issue. Being one of "those
> less knowledge of the underlying concepts," I can personally
> that I would not have immediately understood the difference between
> notify_one and notify_all if signal and broadcast had been used
This was the argument that I found compelling enough to listen to
initially. However, I'm feeling the inertia of history here. No
matter how compelling the argument is to use the more descriptive
names, the fact is that choosing a name that differs from vast
amounts of historical practice can actually lead to a lot of
confusion. Even the "newbies" are going to have to read a lot of
literature to be able to use any threading library safely and
effectively, and when all such literature uses different terminology
it can make it difficult to adjust for them. I just think it will be
confusing when all the literature and every other language/library
that discusses this concept uses one set of names, and Boost.Threads
chooses to use another.
> Another naming issue that has been raised before, and which I do
> feel has ever been addressed thoroughly, deals with semaphore::up()
> and semaphore::down(). I feel strongly that these should instead
> named semaphore::increment() and semaphore::decrement(),
> respectively. This change would serve only to clarify the meaning
> these functions for the following reasons:
> 1) "Increment" and "decrement" are verbs. While "up" and "down"
> also have verb uses, their use as adjectives, adverbs, etc. is much
> more common. A verb naming implies an action being done; an
> adjectival naming implies a property being returned. Since the
> latter is obviously not the case here, "increment" and "decrement"
> are the less ambiguous and thus, IMO, the better choices.
> 2) Since a "semaphore" (in English) is "a system of visual
> signaling by two flags held one in each hand" (from www.m-w.com),
> names "up" and "down" make the subtle implication to an
> user that a semaphore can be only "up" or "down" (as a flag can
> be up or down) -- which is obviously not the case with a
> boost::semaphore. Rather, since these are counting
> semaphores, "increment" and "decrement" instantly convey the multi-
> valued possibilities of the semaphore rather than that of boolean
> up/down values.
> Is there something about semaphores that I am just not
> here? I don't think so, but I'd be happy to learn otherwise.
No, you don't see this one being discussed because I agree with the
name change. Plans are already in place to change this one.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk