« Previous Lecture  |  Next Lecture »

The Linux Kernel Semaphore API

Linux does provide a semaphore object alongside the mutex. Its core operations are:

• Acquire with down(), or the interruptible form down_interruptible()
• Release with up()

The semaphore is the older of the two mechanisms in kernel history, and modern kernel guidance is to reach for a mutex whenever a simple binary lock is all you need, reserving the semaphore for the specific signaling role described below.

Mutex and Semaphore Are Solving Different Problems

The two objects are conceptually distinct, not just two names for the same primitive:

Three points are worth calling out individually:

• Generality: a semaphore is a more general primitive than a mutex. A mutex can be locked and later unlocked exactly once at a time, whereas a (counting) semaphore can be acquired and released multiple times, tracking a count rather than a strict binary state.
• Purpose: a mutex exists to protect a critical section from simultaneous access by multiple threads. A semaphore is better thought of as a signaling mechanism — one task (a “producer”) posts to the semaphore once some milestone is reached, and another task (a “consumer”) that is waiting on that semaphore wakes up and continues.
• Ownership: a mutex has a defined owner — only the thread that locked it may unlock it, and the kernel can enforce or at least assume this. A binary semaphore has no ownership concept at all; any thread can call up() on it, even one that never called down().

Original Demo: Producer/Consumer Signaling with a Semaphore

The following short example, written for this course, shows the signaling use case a mutex cannot express cleanly — one thread announcing that data is ready, and another thread waiting for that announcement.

#include <linux/kthread.h>
#include <linux/semaphore.h>
#include <linux/delay.h>

static struct semaphore ep_data_ready_sem;
static int ep_shared_value;

/* Producer: computes a value, then signals that it is ready */
static int ep_producer_thread(void *arg)
{
    while (!kthread_should_stop()) {
        msleep(1000);
        ep_shared_value = 42; /* pretend this is meaningful work */
        pr_info("ep_sem_demo: producer posting data-ready signal\n");
        up(&ep_data_ready_sem);
    }
    return 0;
}

/* Consumer: waits for the producer's signal before using the value */
static int ep_consumer_thread(void *arg)
{
    while (!kthread_should_stop()) {
        if (down_interruptible(&ep_data_ready_sem))
            break;
        pr_info("ep_sem_demo: consumer read value %d\n", ep_shared_value);
    }
    return 0;
}

Notice that neither thread “owns” ep_data_ready_sem — the producer only ever posts (up()) and the consumer only ever waits (down_interruptible()). That asymmetric, ownerless usage is exactly what a mutex is not designed to express, and it is why the kernel keeps both primitives available for their respective roles.

Aspect	Mutex	Semaphore
Primary role	Mutual exclusion of a critical section	Signaling between tasks
Ownership	Yes, only the locker may unlock	None
Count	Binary, locked once	Can be counting
Modern kernel guidance	Preferred for simple locking	Use only for its signaling role

Priority Inversion: A Locking Hazard Beyond Deadlocks

Careful lock ordering helps you avoid deadlocks, which we covered earlier in this chapter. But there is a second, subtler hazard that any locking scheme can trigger: priority inversion. This happens when a high-priority thread ends up waiting, indirectly, on a lower-priority thread — effectively inverting the priorities the scheduler was supposed to respect.

The unbounded version of this scenario — where the high-priority thread’s wait time has no upper limit because medium-priority threads keep preempting the lock holder — can be severe. Left unaddressed, it means the product’s most important thread is kept off the CPU for an unpredictable, potentially very long time, even though the scheduler was designed to always favour it.

How the Kernel Mitigates Priority Inversion: the RT-Mutex

The classic mitigation technique is priority inheritance: when a high-priority thread blocks on a lock held by a lower-priority thread, the lock holder temporarily “inherits” the waiter’s higher priority for as long as it holds the lock. This prevents medium-priority threads from being able to preempt the lock holder and stall the high-priority waiter indefinitely. Linux implements this through its RT-mutex infrastructure, which underlies the kernel’s real-time locking primitives and is also the basis for the PREEMPT_RT real-time kernel configuration we introduced earlier in this chapter. In practice, as a driver author you rarely call RT-mutex APIs directly — the important takeaway is architectural: understand that priority inversion exists, keep critical sections short, and be aware that the kernel’s own locking primitives are designed with this hazard in mind.

Practical Takeaways

• Use a mutex to protect a critical section; use a semaphore (or, in modern kernel code, a struct completion) when you need one task to signal another.
• Never assume a specific thread “owns” a semaphore — any thread can post to it, so design your signaling logic accordingly.
• Keep every critical section as short as possible; the longer a lock is held, the larger the window for priority inversion to bite.
• Be aware that lockdep, covered in the next chapter, focuses on deadlock detection, while priority inversion is a separate, scheduling-level hazard that the RT-mutex/priority-inheritance mechanism specifically addresses.

Frequently Asked Questions

« Previous Lecture  |  Next Lecture »