Semaphore (programming)

For other uses, see Semaphore.

In computer science, a semaphore is a protected variable or abstract data type which constitutes the classic method for restricting access to shared resources such as shared memory in a multiprogramming environment. A counting semaphore is a counter for a set of available resources, rather than a locked/unlocked flag of a single resource. It was invented by Edsger Dijkstra. Semaphores are the classic solution to preventing race conditions in the dining philosophers problem, although they do not prevent resource deadlocks.

Introduction

Semaphores can only be accessed using the following operations. Those marked atomic should not be interrupted (that is, if the system decides that the "turn is up" for the program doing this, it shouldn't stop it in the middle of those instructions) for the reasons explained below.

P(Semaphore s) // Acquire Resource
{
  wait until s > 0, then s := s-1;
  /* must be atomic because of race conditions */
}

V(Semaphore s)  // Release  Resource
{
  s := s+1;   /* must be atomic */
}

Init(Semaphore s, Integer v)
{
  s := v;
}

Notice that incrementing the variable s must not be interrupted, and the P operation must not be interrupted after s is found to be greater than 0. This can be done using a special instruction such as test-and-set (if the architecture's instruction set supports it), or (on uniprocessor systems) ignoring interrupts in order to prevent other processes from becoming active.

The value of a semaphore is the number of units of the resource which are free. (If there is only one resource, a "binary semaphore" with values 0 or 1 is used.) The P operation busy-waits (uses its turn to do nothing) or maybe sleeps (tells the system not to give it a turn) until a resource is available, whereupon it immediately claims one. V is the inverse; it simply makes a resource available again after the process has finished using it. Init is only used to initialize the semaphore before any requests are made. The P and V operations must be atomic, which means that no process may ever be preempted in the middle of one of those operations to run another operation on the same semaphore.

The canonical names P and V come from the initials of Dutch words. V stands for verhogen, or "increase". Several explanations have been given for P (including proberen for "to test"^[1], passeer for "pass", probeer "try", and pakken "grab"), but in fact Dijkstra wrote that he intended P to stand for the made-up portmanteau word prolaag,^[2] short for probeer te verlagen, or "try-and-decrease" ^[3]^[4] (A less ambiguous, and more accurate, English translation would be "try-to-decrease".) This confusion stems from the unfortunate characteristic of the Dutch language that the words for increase and decrease both begin with the letter V, and the words spelled out in full would be impossibly confusing for non–Dutch-speakers.

In the programming language ALGOL 68, in the Linux kernel,^[5] and in some English textbooks, the P and V operations are called, respectively, down and up. In software engineering practice, they are often called wait and signal, or acquire and release, or pend and post. Some texts call them procure and vacate to match the original Dutch initials.

To avoid busy-waiting, a semaphore may have an associated queue of processes (usually a first-in, first out). If a process performs a P operation on a semaphore which has the value zero, the process is added to the semaphore's queue. When another process increments the semaphore by performing a V operation, and there are processes on the queue, one of them is removed from the queue and resumes execution.

The counting semaphore concept can be extended with the ability of claiming or returning more than one 'unit' from the semaphore. This is indeed the way the classical UNIX semaphore works. The modified P and V operations work like this:

P(Semaphore s, integer howmany)
{
  wait until s >= 0;
  s := s - howmany; /* must be atomic operation */
  wait until s >= 0;
}

V(Semaphore s, integer howmany)
{
  s := s+howmany;   /* must be atomic */
}

To understand why it is better than just calling the simple version of P 'howmany' times consider the following problem. Let's say you have a pool of N resources, say fixed size buffers. You may want to use a counting semaphore initialised to N to keep track of the number of the buffers available. When a process wants to allocate a buffer, it calls P on the semaphore and gets a buffer. If there are no buffers available, a process waits until some other process releases a buffer and invokes V on the semaphore.

Consider that there are two processes that respectively want to acquire K < N and L < N buffers, such that K + L > N. The naive implementation would have the first process call the simple decrementing variant P on the semaphore K times, and it would have the second process call the simple decrementing variant P on the semaphore L times. However, this approach can lead to a deadlock: Imagine that the operating system allows the first process to run. Then, when the first process has only acquired control of Z buffers (such that Z < K and Z + L > N), the operating system preempts the first process to allow the second process time to run. The second process begins acquiring buffers. However, when the second process acquires (N - Z) buffers, the semaphore becomes 0 and the second process gets suspended in order to wait for some other process to free up more buffers (because L > N - Z). The operating system eventually allows the first process to resume, continuing its quest to acquire the remaining (K - Z) buffers that it needs. Unfortunately, since the semaphore is 0, the first process cannot complete this task, so it too becomes suspended in order to wait for some other process to free up more buffers. Neither the first nor the second process can acquire enough buffers to continue, and therefore neither returns any buffers to the pool. Thus, they are stuck in a deadlock situation.

With the modified semaphore version, the first process will ask for K buffers (or more precisely, semaphore units), which it will get in an atomic operation, leaving N-K units on the semaphore. Then the second process arrives, decrements the semaphore down to N-K-L and since that is a negative number, will wait. As the first process releases buffers and increments the semaphore, as soon as the semaphore reaches 0 it means that there are L elements available in the pool, the second process can be woken up and can receive all of its buffers.

It should be noted that the semaphore count is not necessarily equal to the buffers available in the pool. The checking and waiting twice for the s >= 0 condition in P is needed to guarantee that as multiple processes are added to the semaphore's waiting list they do not disturb each other's request: a process does not change the semaphore's count until it is next in the queue. In real implementations it is done without actually activating up the waiting process for the intermediate step.

Semaphores today as used by programmers

Semaphores remain in common use in programming languages that do not intrinsically support other forms of synchronization. They are the primitive synchronization mechanism in many operating systems. The trend in programming language development, though, is towards more structured forms of synchronization, such as monitors (though these advanced structures typically employ semaphores behind the scenes). In addition to their inadequacies in dealing with (multi-resource) deadlocks, semaphores do not protect the programmer from the easy mistakes of taking a semaphore that is already held by the same process, and forgetting to release a semaphore that has been taken.

Example usage

Since semaphores have a count associated with them, they may be employed when multiple threads need to achieve an objective cooperatively. Consider this example:

A thread named A needs information from two databases before it can proceed. Access to these databases is controlled by two separate threads B, C. These two threads have a message-processing loop; anybody needing to use one of the databases posts a message into the corresponding thread's message queue. Thread A initializes a semaphore S with init(S,-1). A then posts a data request, including a pointer to the semaphore S, to both B and C. Then A calls P(S), which blocks. The other two threads meanwhile take their time obtaining the information; when each thread finishes obtaining the information, it calls V(S) on the passed semaphore. Only after both threads have completed will the semaphore's value be positive and A be able to continue. A semaphore used in this way is called a "counting semaphore."

Apart from a counting semaphore, there is a "blocking semaphore". A blocking semaphore is a semaphore that is initialized to zero. This has the effect that any thread that does a P(S) will block until another thread does a V(S). This kind of construct is very useful when the order of execution among threads needs to be controlled.

Hardware support

The use of semaphores normally requires hardware support to guarantee the atomicity of operations that require it. Computer machine languages typically include instructions that are designed specifically with semaphores in mind. These special instructions carry out a read-alter-rewrite cycle to memory that is not only uninterruptible but excludes all other operations to the same location in memory by any other processors or input/output devices. The special instructions guarantee that a semaphore procedure using them can test and alter a semaphore in a single, atomic operation.

Binary semaphore vs. Mutex

A binary semaphore is very similar to a mutex^[6]^[7]. However, there is an important difference – a binary semaphore has no notion of ownership, unlike a mutex. The ownership (or lack thereof) has several related consequences

a binary semaphore can be initialized to either 0 or 1; a mutex is always created in an unlocked state (some implementations allow creation and initial acquisition to be performed atomically ^[8])
different processes can decrement and/or increment a binary semaphore; only the current owner of a mutex can unlock it ^[9]^[10]
binary semaphores can't implement Priority inheritance (but can implement Priority ceiling protocol); mutexes can implement both
binary semaphores can be used for event notification and mutual exclusion; mutexes alone can only be used for mutual exclusion

All of these differences can be seen in the solution of the producer-consumer problem using semaphores for the case BUFFER_SIZE==1: one of the semaphores is initialized to zero, whereas the other one is initialized to 1; for both semaphores, the process, which decrements them is different from the process that increments them; semaphores are used as an event notification mechanism - notifying about the occurance of the events item becoming available and buffer space becoming available.

References

^ Silberschatz, Galvin, & Gagne 8th Ed. p.234
^ http://www.cs.utexas.edu/users/EWD/ewd00xx/EWD74.PDF
^ http://www.cs.utexas.edu/users/EWD/transcriptions/EWD00xx/EWD51.html MULTIPROGAMMERING EN DE X8 from the E.W. Dijkstra Archive (in Dutch)
^ http://lkml.org/lkml/2005/12/19/34 Linux Kernel Mailing List: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
^ Kernel hacking howto on linuxgrill.com
^ http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap03.html#tag_03_229 Definition in The Open Group Base Specifications Issue 6
^ http://msdn.microsoft.com/en-us/library/ms686927(VS.85).aspx MSDN: Using Mutex Objects
^ http://msdn.microsoft.com/en-us/library/ms682411(VS.85).aspx MSDN: CreateMutex Function
^ http://www.opengroup.org/onlinepubs/000095399/functions/pthread_mutex_lock.html The Open Group Base Specifications Issue 6: man pthread_mutex_lock
^ http://msdn.microsoft.com/en-us/library/ms685066(VS.85).aspx MSDN: ReleaseMutex Function

Silberschatz, Abraham; Galvin, Peter Baer; Gagne, Greg (2008), Operating System Concepts (8th ed.), John Wiley & Sons. Inc, ISBN 978-0-470-12872-5
The Little Book of Semaphores, by Allen B. Downey, Green Tea Press.

External links

Over Seinpalen (EWD 74), in which Dijkstra introduces the concept (in Dutch)
semaphore.h programming interface - The Open Group Base Specifications Issue 6, IEEE Std 1003.1
The Little Book of Semaphores, by Allen B. Downey

[1] Silberschatz, Galvin, & Gagne 8th Ed. p.234

[2] ttp://www.cs.utexas.edu/users/EWD/ewd00xx/EWD74.PDF

[3] ttp://www.cs.utexas.edu/users/EWD/transcriptions/EWD00xx/EWD51.html MULTIPROGAMMERING EN DE X8 from the E.W. Dijkstra Archive (in Dutch)

[4] ttp://lkml.org/lkml/2005/12/19/34 Linux Kernel Mailing List: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

[5] Kernel hacking howto on linuxgrill.com

[6] ttp://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap03.html#tag_03_229 Definition in The Open Group Base Specifications Issue 6

[7] ttp://msdn.microsoft.com/en-us/library/ms686927(VS.85).aspx MSDN: Using Mutex Objects

[8] ttp://msdn.microsoft.com/en-us/library/ms682411(VS.85).aspx MSDN: CreateMutex Function

[9] ttp://www.opengroup.org/onlinepubs/000095399/functions/pthread_mutex_lock.html The Open Group Base Specifications Issue 6: man pthread_mutex_lock

[10] ttp://msdn.microsoft.com/en-us/library/ms685066(VS.85).aspx MSDN: ReleaseMutex Function

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]