NOTE: This interface, and its subclasses, are deprecated. With J2SE 5.0 (a.k.a., Java 1.5), the JDK provides its own semaphore class, java.util.concurrent.Semaphore.
The Semaphore interface specifies a classic counting semaphore. This interface can be implemented in a variety of ways, including (but not limited to) the following:
The following description of a semaphore is paraphrased from An Introduction to Operating Systems, by Harvey M. Deitel (Addison-Wesley, 1983, p. 88):
"[Edsgar] Dijkstra developed the concept of semaphores ... as an aid to synchronizing processes. A semaphore is a variable that can be operated upon only by the synchronizing primitives, P and V (letters corresponding to words in Dijkstra's native language, Dutch) defined as follows:
- P(S): wait for S to become greater than zero and then subtract 1 from S and proceed
- V(S): add 1 to S and then proceed
"P allows a process to block itself voluntarily while it waits for an event to occur. V allows another process to wake up a blocked process. Each of these operations must be performed indivisibly; that is, the are not interruptible. The V-operation cannot block the process that performs it."
Within this Semaphore class, the P operation corresponds to the {@link #acquire()} method, and the V operation corresponds to the{@link #release()} method.
In other programming languages, one common use for a semaphore is to lock a critical section. For example, a semaphore is often used to synchronize access to a data structure that's shared between one or more processes or threads. Since the Java language has built in support for interthread synchronization (via the synchronized keyword), semaphores are not needed for that purpose in Java.
However, semaphores are still useful in some scenarios. Consider the case where you have a fixed-size pool of shared buffers to be shared between all running threads. For whatever reason, you cannot allocate more buffers; you're stuck with the fixed number. How do you control access to the buffers when there are more threads than there are buffers? A semaphore makes this job much easier:
If a thread attempts to allocate a buffer from the pool, and there is at least one buffer in the pool, the thread's attempt to acquire the semaphore will succeed, and it can safely get the buffer. However, if there are no buffers in the pool, the buffer pool semaphore will be 0, and the thread will have to wait until (a) a buffer is returned to the pool, which will "kick" the semaphore and awaken the thread, or (b) the semaphore's acquire() method times out.
@version $Revision$ @deprecated J2SE 5.0 now provides a java.util.concurrent.Semaphore class @author Copyright © 2004-2007 Brian M. Clapper | |