POSIX Semaphores

Learning Objectives

• Understand semaphore fundamentals.
• Learn binary and counting semaphores.
• Understand named and unnamed semaphores.
• Study the semaphore lifecycle.
• Prepare for synchronization APIs.

1. What is a Semaphore?

A semaphore is a synchronization object that controls access to shared resources. It maintains an internal counter. Processes or threads decrement the counter before entering a protected section and increment it after leaving. If the counter reaches zero, additional requests must wait until another execution context releases the semaphore.

2. Why are Semaphores Needed?

3. Semaphore Concept

4. Binary Semaphore

A binary semaphore has only two logical states:

Binary semaphores are commonly used to provide mutual exclusion for a single shared resource.

5. Counting Semaphore

A counting semaphore allows multiple concurrent users. The counter represents the number of available resource instances.

6. Binary vs Counting Semaphore

7. Named vs Unnamed Semaphores

8. Semaphore Data Type (sem_t)

POSIX semaphores are represented using the opaque sem_t data type. Applications treat sem_t as an abstract object and manipulate it only through the POSIX semaphore APIs.

9. Linux Implementation

On Linux, named POSIX semaphores are typically implemented using the /dev/shm shared memory filesystem. Semaphore objects often appear with names beginning with sem.

The exact implementation is Linux-specific; applications should use only the POSIX APIs and not depend on filesystem details.

10. Interview Questions

1. What is a semaphore?
2. Why are semaphores used?
3. How does a semaphore differ from a mutex?
4. What is the difference between binary and counting semaphores?
5. When should you use a counting semaphore?
6. What is a named semaphore?
7. What is an unnamed semaphore?
8. Which type is represented by sem_t?
9. Where are named semaphores commonly implemented on Linux?
10. Can semaphores transfer application data?

11. sem_open()

The sem_open() function creates a new named semaphore or opens an existing one. Named semaphores allow unrelated processes to synchronize by opening the same semaphore name.

12. sem_open() Parameters

13. Semaphore Creation Flags

When O_CREAT and O_EXCL are used together, creation succeeds only if the semaphore name does not already exist.

14. sem_close()

The sem_close() function closes a named semaphore descriptor previously returned by sem_open(). Closing the semaphore releases the calling process's reference but does not remove the semaphore from the system.

15. sem_unlink()

The sem_unlink() function removes the name associated with a named semaphore. The semaphore object remains available until every process has closed its reference.

16. sem_init()

The sem_init() function initializes an unnamed semaphore. Unnamed semaphores are typically used for threads or related processes that share memory.

17. sem_destroy()

The sem_destroy() function destroys an unnamed semaphore that was initialized using sem_init(). It must not be used for named semaphores.

18. Permission Bits

19. Example: Creating a Named Semaphore

20. Linux Commands

21. Interview Questions

1. What is the difference between sem_open() and sem_init()?
2. When should a named semaphore be used?
3. When should an unnamed semaphore be used?
4. Why is pshared needed?
5. What does SEM_FAILED indicate?
6. What is the purpose of sem_close()?
7. Why is sem_unlink() required?
8. Why must sem_destroy() not be used on named semaphores?
9. What is the effect of O_EXCL?
10. What permissions are assigned during semaphore creation?

22. sem_wait()

The sem_wait() function attempts to decrement (acquire) the semaphore. If the semaphore value is greater than zero, it is decremented immediately. If the semaphore value is zero, the calling thread or process blocks until another execution context releases the semaphore.

23. sem_trywait()

The sem_trywait() function performs the same operation as sem_wait(), but never blocks. If the semaphore cannot be acquired immediately, the function returns an error.

24. sem_timedwait()

The sem_timedwait() function waits until either:

• The semaphore becomes available, or
• The specified timeout expires.

If the timeout expires before the semaphore becomes available, the function returns -1 and sets errno to ETIMEDOUT.

25. sem_post()

The sem_post() function increments (releases) a semaphore. If one or more execution contexts are blocked in sem_wait(), the kernel wakes one of them.

26. sem_getvalue()

The sem_getvalue() function retrieves the current semaphore value.

The returned value should be used only for monitoring or debugging. Applications should not rely on it for synchronization because the value may change immediately after it is read.

27. Semaphore State Transition

28. Example: Binary Semaphore

Only one execution context can enter the critical section at a time.

29. Producer–Consumer Synchronization

Semaphores coordinate access to the shared buffer while preventing overflow and underflow.

30. Linux Debugging Commands

31. Advanced Interview Questions

1. What is the difference between sem_wait() and sem_trywait()?
2. When should sem_timedwait() be used?
3. What error is returned by sem_trywait() if the semaphore is unavailable?
4. What happens when sem_post() is called?
5. Can multiple waiting threads be awakened by one sem_post()?
6. Why is sem_getvalue() unsuitable for synchronization decisions?
7. How does a binary semaphore protect a critical section?
8. How do semaphores solve the Producer–Consumer problem?
9. What happens if sem_wait() is called when the semaphore value is zero?
10. What timeout error is returned by sem_timedwait()?

32. Semaphore Lifecycle

For unnamed semaphores, the lifecycle differs:

33. Named vs Unnamed Semaphore Comparison

34. Common Programming Mistakes

• Calling sem_wait() without a matching sem_post().
• Destroying a semaphore while another thread is still using it.
• Using sem_destroy() on a named semaphore.
• Forgetting to call sem_unlink() for named semaphores.
• Acquiring multiple semaphores in inconsistent order.
• Ignoring API return values.
• Sharing an unnamed semaphore without shared memory.

35. Deadlock Prevention

Semaphores themselves do not prevent deadlocks. Applications must follow consistent locking strategies.

36. Best Practices

• Always pair every sem_wait() with sem_post().
• Use named semaphores only when unrelated processes must synchronize.
• Prefer unnamed semaphores for thread synchronization.
• Always check API return values.
• Destroy or unlink semaphores during application shutdown.
• Keep critical sections as short as possible.
• Document semaphore ownership and acquisition order.

37. Debugging Tips

38. Advanced Interview Questions

1. Explain the lifecycle of a named semaphore.
2. Explain the lifecycle of an unnamed semaphore.
3. Why are unnamed semaphores generally preferred for threads?
4. What happens if sem_post() is forgotten?
5. How can semaphore misuse cause deadlocks?
6. Why should semaphores always be acquired in a fixed order?
7. When should sem_timedwait() be preferred?
8. Can multiple threads wait on the same semaphore?
9. How does a semaphore differ from a mutex regarding resource counting?
10. Why should sem_getvalue() not be used for synchronization logic?

39. Module Summary

In this module, we studied POSIX Semaphores in detail. We covered semaphore fundamentals, binary and counting semaphores, named and unnamed semaphores, semaphore creation APIs (sem_open() and sem_init()), synchronization operations (sem_wait(), sem_trywait(), sem_timedwait(), sem_post()), resource cleanup APIs (sem_close(), sem_unlink(), sem_destroy()), deadlock prevention techniques, debugging strategies, and recommended programming practices. POSIX semaphores provide efficient synchronization for both multi-threaded applications and cooperating processes.