Questions: Semaphores

Question 1

A parent thread must wait until a child thread finishes initialization before proceeding. Which approach is most appropriate?

• A. A mutex initialized to locked — the parent acquires the lock and the child releases it after finishing
• B. A semaphore initialized to 0 — the parent calls wait (blocking), and the child calls signal after initialization completes
• C. A mutex initialized to unlocked — the parent polls in a loop until it can acquire the lock
• D. A semaphore initialized to 1 — both threads call wait, and whichever succeeds first proceeds

Answer: (B)

This is the signaling pattern that semaphores handle and mutexes cannot. The semaphore starts at 0 (no 'credits'), so the parent's wait immediately blocks. When the child finishes, it signals — incrementing the counter and unblocking the parent. A mutex cannot do this cleanly because mutexes require the same thread to both acquire and release; here, the child releases what the parent is waiting on, which is a different thread.

Question 2

A bounded buffer holds up to 5 items. You use a counting semaphore 'empty' (initialized to 5) and 'full' (initialized to 0). A producer wants to insert an item. What is the correct sequence?

• A. Signal 'empty', insert the item, then signal 'full'
• B. Wait on 'full', insert the item, then signal 'empty'
• C. Wait on 'empty', insert the item, then signal 'full'
• D. Wait on both 'empty' and 'full' before inserting

Answer: (C)

The producer must first claim an empty slot (wait on 'empty' — decrement the count of available empty slots; block if zero), insert the item, then announce a new full slot (signal 'full' — increment the count of full slots, potentially waking a waiting consumer). Waiting on 'full' (option B) would mean waiting until the buffer is full before inserting, which is backwards.

Question 3

A binary semaphore and a mutex are functionally identical because both restrict access to one thread at a time.

• T. True
• F. False

Answer: False

The critical difference is ownership. A mutex must be released by the same thread that acquired it — ownership is thread-bound. A semaphore can be signaled by any thread, regardless of which thread called wait. This distinction makes semaphores suitable for inter-thread signaling (parent waits for child's completion), a pattern that requires one thread to 'unlock' what another is waiting on — which mutex semantics explicitly forbid.

Question 4

Calling signal (V) on a semaphore when no threads are blocked still increments the counter, effectively saving the signal as a credit for a future wait call.

• T. True
• F. False

Answer: True

Signal unconditionally increments the counter. If threads are blocked, one is woken; if none are blocked, the counter simply increments. This 'saved credit' behavior is important: if the signaling thread runs before the waiting thread, the wait call will find the counter already positive and proceed without blocking. This is one key advantage of semaphores over condition variables, which lose signals if no thread is waiting.

Question 5

Why is it correct to say semaphores 'generalize' mutexes rather than simply being a different kind of lock?

Model answer: A mutex is a binary, ownership-bound lock: only two states (locked/unlocked), and the same thread must release it. A semaphore replaces the binary state with an integer counter, enabling a superset of behaviors: a binary semaphore replicates mutual exclusion (values 0 and 1), while counting semaphores track N available resources and allow any thread to signal. Mutexes are a special case of the semaphore concept, not a parallel idea — which is why 'generalize' is the right word.

This framing matters practically: when a mutex isn't expressive enough (e.g., for producer-consumer coordination or thread signaling), reaching for a semaphore is the natural next step. Understanding mutexes as a degenerate case of semaphores, rather than as a separate concept, clarifies why semaphores are more powerful and more error-prone.