A mutex has a strict ownership rule: only the thread that locked the mutex can unlock it. This enforces a clear lock/unlock pattern within the same scope and prevents accidental unlock by unrelated code.

A semaphore has no ownership. Thread A can decrement it and Thread B can increment it. While this flexibility is sometimes useful, it can lead to poorly structured synchronization designs where it is unclear which code is responsible for releasing a resource.

This is why semaphores are sometimes called the “gotos of concurrent programming” — they work, but can make code hard to reason about.

sem_post() is async-signal-safe. This means it can safely be called from within a signal handler. Pthreads mutex functions are NOT async-signal-safe — calling pthread_mutex_unlock() from a signal handler results in undefined behavior.

This matters when you need a signal handler to wake up a blocking thread. The recommended pattern:

/*
 * Pattern: signal handler posts a semaphore to wake a waiting thread.
 * Works because sem_post() is async-signal-safe.
 */
#include <semaphore.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

static sem_t sig_sem;

/* Signal handler: just post the semaphore */
static void sigint_handler(int sig) {
    sem_post(&sig_sem);   /* async-signal-safe: OK */
}

/* Thread that waits for a signal via semaphore */
static void *waiter_thread(void *arg) {
    printf("Thread: waiting for signal...\n");
    sem_wait(&sig_sem);
    printf("Thread: received signal, cleaning up.\n");
    return NULL;
}

int main(void) {
    pthread_t tid;
    struct sigaction sa;

    sem_init(&sig_sem, 0, 0); /* start at 0: thread will block */

    sa.sa_handler = sigint_handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGINT, &sa, NULL);

    pthread_create(&tid, NULL, waiter_thread, NULL);
    pthread_join(tid, NULL);

    sem_destroy(&sig_sem);
    return 0;
}
/* Press Ctrl+C to trigger SIGINT and wake the thread */
/* Compile: gcc -o sig_sem sig_sem.c -lpthread */

Note from TLPI: It is usually more elegant to handle async signals using sigwaitinfo() rather than signal handlers (see Section 33.2.4). This makes the semaphore advantage over mutexes in signal handling less commonly needed in practice.

POSIX semaphores on Linux are implemented using futexes (fast user-space mutexes). When the semaphore value allows an operation to proceed without blocking, the operation is completed with an atomic user-space instruction and no system call is made. System V semaphore operations (semop) always make a system call regardless of whether blocking is needed, causing kernel overhead every time.

In System V, creating a semaphore set (semget) and initializing it (semctl with SETVAL) are two separate steps. Another process could use the semaphore between these steps when it is in an undefined state. POSIX sem_open() with O_CREAT atomically creates AND sets the initial value in a single step, eliminating the window entirely.

Mutexes enforce ownership: only the thread that acquired the lock can release it. This enforces disciplined coding — the lock and unlock always appear in the same scope/function. Semaphores have no ownership, so any thread can increment them, which can lead to accidental double-release or mismatched acquire/release patterns — bugs that are hard to detect.

Just as goto in sequential code can make control flow hard to follow, semaphore operations scattered across different threads can make synchronization flow hard to reason about. Because sem_post() and sem_wait() can be called by unrelated code in any order with no ownership constraint, it is easy to create synchronization patterns that are correct but difficult to understand, maintain, or audit.

SEM_UNDO is a flag for semop() that asks the kernel to automatically reverse any semaphore operations when the process terminates. This prevents deadlock if a process crashes while holding a semaphore. POSIX semaphores have no equivalent. However, TLPI notes that SEM_UNDO has limitations (it doesn’t work well across fork, and has per-process adjustment limits), so in many real-world scenarios it is not as useful as it sounds.

Yes. sem_post() is listed as async-signal-safe in POSIX (Table 21-1 in TLPI), meaning it is safe to call from a signal handler. This makes it possible to use a semaphore to wake up a blocked thread from a signal handler. Mutex functions (pthread_mutex_lock/unlock) are NOT async-signal-safe and cannot be used in signal handlers.