Re: Review: Boost.Threads

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 
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), 
the
> > names "up" and "down" make the subtle implication to an 
inexperienced
> > user that a semaphore can be only "up" or "down" (as a flag can 
only
> > 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 
understanding
> > 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.  
Reasoning:

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 
history.

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 
chosen.

Bill Kempf