Semaphore

A semaphore is a synchronization object that controls access or signalling with an integer permit count. A task waits when no permit is available and continues when a permit is granted or posted.

Semaphores appear in operating systems, embedded firmware, real-time software, device drivers, connection pools, bounded queues and producer-consumer pipelines. They are different from mutexes because they do not always imply single ownership. A task may post an event that another task waits on, and a counting semaphore may represent many identical resources.

Permit Count

Let maximum permit capacity be:

and current available permits be:

A valid counting semaphore should satisfy:

The number of permits currently in use is:

If P becomes negative, the implementation is not a counting semaphore; it may be representing waiters separately. If P rises above K, the design may have an over-release bug.

Wait and Post

A wait operation attempts to consume one permit:

when:

If no permit is available, the task waits, blocks, spins, times out or fails depending on the API. A post operation releases or signals one permit:

bounded by the configured maximum. The design must state whether posting without a matching completed operation is allowed.

Resource Limit

Semaphores can limit a pool of identical resources: connections, buffers, DMA descriptors, worker slots, outstanding commands or in-flight messages. If arrivals acquire permits at rate:

and average permit hold time is:

then average permit demand is:

A capacity screen is:

Sustained operation needs:

with margin for bursts, long holds, retries, failed releases and priority classes.

Producer-Consumer Signalling

A bounded buffer often uses two semaphores. The items semaphore counts data available to consume:

The slots semaphore counts free locations available to producers:

For buffer capacity:

the invariant is:

A producer waits on S_slots, writes an item, then posts S_items. A consumer waits on S_items, removes an item, then posts S_slots. The semaphore counts do not replace the need to protect complex buffer metadata when multiple producers or consumers update shared indices.

Worked Capacity Check

A service uses a semaphore to limit concurrent access to a downstream dependency:

Admitted request rate is:

and average permit hold time is:

Average permit demand is:

The semaphore utilization screen is:

This passes as a first screen. If an error path leaks:

permits, effective capacity becomes:

and:

The system is now near saturation without any real traffic growth.

Boundary With Mutexes

A mutex protects ownership of a critical section. A semaphore counts permits or events. A binary semaphore can look like a mutex, but it may not enforce owner unlock, priority inheritance or recursive-lock rules. Using a binary semaphore as a mutex in a real-time path is risky unless the scheduler and API semantics are explicitly verified.

Timeout and Fairness

Semaphore waits should usually have a defined timeout when the caller has a deadline or recovery obligation. An indefinite wait may be acceptable for a background consumer, but it is weak evidence for a control path, medical device, gateway or service request with a caller timeout.

For a wait timeout:

and useful caller deadline:

the semaphore wait must leave enough time for service, cleanup or safe fallback:

Fairness also matters. A semaphore that wakes waiters in an unfair order may let high-rate or high-priority producers repeatedly consume permits while low-rate maintenance work starves. If priority order is required, the semaphore policy should be part of the design, not an assumed property of the runtime.

Failure Modes

Common semaphore failures include permit leaks, over-release, missed post, wait without timeout, starvation under unfair wakeup, priority inversion, deadlock from holding a permit while waiting for another resource, and treating permit count as proof that downstream latency is acceptable.

Validation Evidence

Useful evidence includes minimum and maximum permit count, wait-time distribution, timeout counters, over-release detection, leak tests on error paths, producer-consumer invariant checks, fairness tests, priority traces, watchdog behavior and load tests with dependency stalls. The release claim should connect semaphore behavior to queue length, data age, deadline margin, retry behavior and degraded-mode rules.