|
Boost : |
From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-07-19 08:14:34
boost::semaphore::up
boost::semaphore::down
vs large industry (IEEE/Open Group) consensus: lock/unlock..
3212 4.15 Semaphore
3213 A minimum synchronization primitive to serve as a basis for more
complex synchronization
3214 mechanisms to be defined by the application program.
3215 For the semaphores associated with the Semaphores option, a semaphore
is represented as a
3216 shareable resource that has a non-negative integer value. When the
value is zero, there is a
3217 (possibly empty) set of threads awaiting the availability of the
semaphore.
3218 For the semaphores associated with the X/Open System Interface
Extension (XSI), a semaphore
3219 is a positive integer (0 through 32767). The semget( ) function can be
called to create a set or array
3220 of semaphores. A semaphore set can contain one or more semaphores up
to an implementation-
3221 defined value.
3222 Semaphore Lock Operation
^^^^
3223 An operation that is applied to a semaphore. If, prior to the
operation, the value of the
3224 semaphore is zero, the semaphore lock operation shall cause the
calling thread to be blocked and
3225 added to the set of threads awaiting the semaphore; otherwise, the
value shall be decremented.
3226 Semaphore Unlock Operation
^^^^^^
3227 An operation that is applied to a semaphore. If, prior to the
operation, there are any threads in
3228 the set of threads awaiting the semaphore, then some thread from that
set shall be removed from
3229 the set and becomes unblocked; otherwise, the semaphore value shall be
incremented.
btw..
4404 Much experience with semaphores shows that there are two distinct uses
of synchronization:
4405 locking, which is typically of short duration; and waiting, which is
typically of long or
4406 unbounded duration. These distinct usages map directly onto mutexes
and condition
4407 variables, respectively.
4408 Semaphores are provided in IEEE Std 1003.1-200x primarily to provide a
means of
4409 synchronization for processes; these processes may or may not share
memory. Mutexes and
4410 condition variables are specified as synchronization mechanisms
between threads; these
4411 threads always share (some) memory. Both are synchronization paradigms
that have been in
4412 widespread use for a number of years. Each set of primitives is
particularly well matched to
4413 certain problems.
4414 With respect to binary semaphores, experience has shown that condition
variables and
4415 mutexes are easier to use for many synchronization problems than
binary semaphores. The
4416 primary reason for this is the explicit appearance of a Boolean
predicate that specifies when
4417 the condition wait is satisfied. This Boolean predicate terminates a
loop, including the call to
4418 pthread_cond_wait( ). As a result, extra wakeups are benign since the
predicate governs
4419 whether the thread will actually proceed past the condition wait. With
stateful primitives,
4420 such as binary semaphores, the wakeup in itself typically means that
the wait is satisfied. The
4421 burden of ensuring correctness for such waits is thus placed on all
signalers of the semaphore
4422 rather than on an explicitly coded Boolean predicate located at the
condition wait. Experience
4423 has shown that the latter creates a major improvement in safety and
ease-of-use.
4424 Counting semaphores are well matched to dealing with producer/consumer
problems,
4425 including those that might exist between threads of different
processes, or between a signal
4426 handler and a thread. In the former case, there may be little or no
memory shared by the
4427 processes; in the latter case, one is not communicating between
co-equal threads, but |
4428 between a thread and an interrupt-like entity. It is for these reasons
that IEEE Std 1003.1-200x |
4429 allows semaphores to be used by threads.
4430 Mutexes and condition variables have been effectively used with and
without priority
4431 inheritance, priority ceiling, and other attributes to synchronize
threads that share memory.
4432 The efficiency of their implementation is comparable to or better than
that of other
4433 synchronization primitives that are sometimes harder to use (for
example, binary
4434 semaphores). Furthermore, there is at least one known implementation
of Ada tasking that
4435 uses these primitives. Mutexes and condition variables together
constitute an appropriate,
4436 sufficient, and complete set of inter-thread synchronization
primitives. |
4437 Efficient multi-threaded applications require high-performance
synchronization primitives.
4438 Considerations of efficiency and generality require a small set of
primitives upon which more
4439 sophisticated synchronization functions can be built.
39299 sem_post -unlock a semaphore (REALTIME)
^^^^^^
39300 SYNOPSIS
39301 SEM #include <semaphore.h>
39302 int sem_post(sem_t * sem);
39303
39304 DESCRIPTION
39305 The sem_post( ) function shall unlock
^^^^^^
the semaphore referenced by sem by performing a
39306 semaphore unlock operation on that semaphore.
^^^^^^^^^^^^^^^^
39406 sem_trywait, sem_wait -lock a semaphore (REALTIME)
^^^^
39407 SYNOPSIS
39408 SEM #include <semaphore.h>
39409 int sem_trywait(sem_t * sem);
39410 int sem_wait(sem_t * sem);
39411
39412 DESCRIPTION
39413 The sem_trywait( ) function shall lock the semaphore referenced by
sem only if the semaphore is
39414 currently not locked; that is, if the semaphore value is currently
positive. Otherwise, shall does
39415 not lock the semaphore.
39416 The sem_wait( ) function shall lock the semaphore referenced by sem
by performing a semaphore
39417 lock operation on that semaphore. If the semaphore value is currently
zero, then the calling
39418 thread shall not return from the call to sem_wait( ) until it either
locks the semaphore or the call is
39419 interrupted by a signal.
39420 Upon successful return, the state of the semaphore shall be locked
and shall remain locked until
39421 the sem_post( ) function is executed and returns successfully.
regards,
alexander.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk