Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-09-25 08:52:42

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> > 1) "Increment" and "decrement" are verbs. While "up" and "down"
> > also have verb uses, their use as adjectives, adverbs, etc. is
> > 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,
> > 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
> > 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.
> semaphores provide synchronization operations (with
> the primary purpose to impose a limit with respect
> to concurrent execution of code regions "protected"
> by semaphores) named by POSIX committee and approved
> by IEEE/ISO as "Semaphore *Lock* Operation" and
> "Semaphore *Unlock* Operation":
> "Semaphore Unlock Operation
> An operation that is applied to a semaphore. If, prior to the
> operation, there are any threads in the set of threads awaiting
> the semaphore, then some thread from that set shall be removed
> from the set and becomes unblocked; ..."
> a) !! NO INCREMENT !!
> "...otherwise, the semaphore value shall be incremented."
> b) INCREMENT; increase level of allowed concurrency.
> "Semaphore Lock Operation
> An operation that is applied to a semaphore. If, prior to the
> operation, the value of the semaphore is zero, the semaphore
> lock operation shall cause the calling thread to be blocked
> and added to the set of threads awaiting the semaphore; ..."
> a) !! NO DECREMENT !!
> "...otherwise, the value shall be decremented."
> b) DECREMENT; decrease level of allowed concurrency.

I will not use the names lock() and unlock() for semaphores.

1) Historical precedence doesn't apply. POSIX may be a standard,
and one that enjoys a long and successful history, but in the grand
scheme of things it's a VERY small part of threading history. I'd
dare to say that even the Win32 threading libraries are used at least
nearly as much as POSIX, and when you combine all other threading
libraries, concurrent languages and literature, POSIX doesn't add
much to history at all. The only names that have any historical
inertia are P() and V(), which everyone agrees are absolutely
terrible names, which is why every library since has chosen more
meaningful ones, and lock()/unlock() don't play that strongly in this

2) The names lock() and unlock() convey a sense of ownership, which
is something foreign to semaphores. No one owns a semaphore. With
both types of semaphores (counting and binary) one thread can
decrement the semaphore and another thread increment it. With a
counting semaphore it's even worse, since two different threads can
decrement the same semaphore. There's simply no concept of ownership
with this type, making the names lock() and unlock() very misleading,
and rendering the semaphore even more dangerous if those names are

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at