• Process:
  • An instance of a program execution
• Interprocess Communication:
  • Processes can exchange data in a variety of different ways
  • Processes often need to coordinate their activities

• Signals:
  • Can be used to notify a process that an event has occurred
• Files:
  • File locks can be used for limited kinds of coordination
• Pipes and FIFOs:
  • Are generally used to exchange information but their blocking and signaling behavior can be used for limited kinds of coordination

• Definition:
  • A semaphore is a kernel-maintained non-negative integer that can be operated on by processes using system calls
• Operations:
  • Setting the value
  • Increasing the value by 1
  • Blocking until the value can be decreased by 1

• In And Of Itself:
  • It has no specific meaning
• In Context:
  • Meaning is given to the semaphore based on the by the coordination protocol that uses it

• Flexibility:
  • Many synchronization protocols can be implemented using semaphores
• Simplicity:
  • It is relatively easy to prove the correctness of a synchronization protocol implemented using semaphores
• Portability:
  • Though the syntax may vary from system to system, the mechanism has been implemented on many systems (though we will only consider the POSIX implementation)

• Unnamed:
  • Reside in a region of shared memory
• Named:
  • Have an associated name and hence can easily be used by unrelated processes

#include <semaphore.h>

O_CREAT is used to create a semaphore. O_CREAT & O_EXCL is used to create a semaphore but fail if it already exists.

• Convention:
  • An initial slash followed by one or more non-slash characters
• Length:
  • Limited to NAME_MAX - 4 characters

• Type:
  • A pointer to a sem_t value
• An Important Restruction:
  • Operations should not be performed on a copy of the pointer (but a child can use the "inherited" references)

#include <semaphore.h>

Note that sem_close() does not delete the semaphore.

• Remember:
  • Named semaphores have kernel persistence
• Implications:
  • You MUST remember to unlink named semaphores
• Getting a List of Semaphores:
  • ls -l /dev/shm/sem.*

• Normal Flow:
  • Decrements the semaphore by 1 and returns immediately if the semaphore has a value greater than 0
  • Otherwise blocks until the value rises above 0 (at which point the semaphore is decremented and the function returns)
• If Interrupted by a Signal Handler:
  • The function fails with the error EINTR (regardless of whther the SA_RESTART flag was used when the signal handler was installed/established)

• sem_trywait()
  • If the value of the semaphore is 0 it fails immediately with the error EAGAIN
• sem_timedwait()
  • Allows for a limit on the amount of time the call will block

• Compiling:
  • As before
• Linking:
  • -pthread

Note: The "sender" transmits one bit of information (as in the similar examples that used signals and pipes) by either incrementing the semaphore or not.

• Recall:
  • In the discussion of signals we made the example more complicated by giving the child another (long) task that the parent did not have to wait for
  • We were unable to create a coordination protocol for this problem
• The Advantage of Semaphores:
  • The are more flexible than wait()

Note: One semaphore is being used to satisfy the sequencing constraint and another is being used for "alerting".

Note: The semaphore is initialized to 1 so that whichever process checks first can "enter".