Re: Boost.Threads - Semaphore Operations

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-07-20 07:04:04

> > boost::semaphore::up
> > boost::semaphore::down
> >
> > vs large industry (IEEE/Open Group) consensus: lock/unlock..
>
> Vs. the POSIX choice of post and wait.

historical reasons.. operations have
"official" names; lock and unlock.

with Boost.Threads you do not have a problem
of renaming a function and breaking millions
lines of code.

consider binary semaphore.. the semantics
completely match mutex.lock/unlock with
only one extra feature - you can transfer
the lock ownership and let another thread
release the lock.

> The long and short, whether these are the accepted industry names or
> not, lock and unlock are meaningless terms when the semantics are to
> increment and decrement a value.

Bill, the semantics are not "to increment and decrement
a value". semaphore is a synchronization mechanism/device
to limit concurrency with "value" used as allowed concurrency
level counter/threshold. i.e. e.g. in the presence of some
thread(s) blocked on semaphore, unlock does not change the
value (the level of allowed concurrency with respect to
semaphore does not increase above achieved maximum).
please, do not mix a possible monitor implementation
(unlock: if ( 0 == value++ ) cond.signal)
with well defined semantics of lock/unlock operations:

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

regards,
alexander.