Before obtaining an item each thread must acquire a permit from the semaphore, guaranteeing that an item is available for use. When the thread has finished with the item it is returned back to the pool and a permit is returned to the semaphore, allowing another thread to acquire that item. Note that no synchronization lock is held when {@link #acquire} is called as that would prevent an itemfrom being returned to the pool. The semaphore encapsulates the synchronization needed to restrict access to the pool, separately from any synchronization needed to maintain the consistency of the pool itself.
A semaphore initialized to one, and which is used such that it only has at most one permit available, can serve as a mutual exclusion lock. This is more commonly known as a binary semaphore, because it only has two states: one permit available, or zero permits available. When used in this way, the binary semaphore has the property (unlike many {@link Lock}implementations), that the "lock" can be released by a thread other than the owner (as semaphores have no notion of ownership). This can be useful in some specialized contexts, such as deadlock recovery.
The constructor for this class optionally accepts a fairness parameter. When set false, this class makes no guarantees about the order in which threads acquire permits. In particular, barging is permitted, that is, a thread invoking {@link #acquire} can be allocated a permit ahead of athread that has been waiting - logically the new thread places itself at the head of the queue of waiting threads. When fairness is set true, the semaphore guarantees that threads invoking any of the {@link #acquire() acquire} methods are selected to obtain permits in the order inwhich their invocation of those methods was processed (first-in-first-out; FIFO). Note that FIFO ordering necessarily applies to specific internal points of execution within these methods. So, it is possible for one thread to invoke acquire before another, but reach the ordering point after the other, and similarly upon return from the method. Also note that the untimed {@link #tryAcquire() tryAcquire} methods do nothonor the fairness setting, but will take any permits that are available.
Generally, semaphores used to control resource access should be initialized as fair, to ensure that no thread is starved out from accessing a resource. When using semaphores for other kinds of synchronization control, the throughput advantages of non-fair ordering often outweigh fairness considerations. @since 1.5 @author Doug Lea
Before obtaining an item each thread must acquire a permit from the semaphore, guaranteeing that an item is available for use. When the thread has finished with the item it is returned back to the pool and a permit is returned to the semaphore, allowing another thread to acquire that item. Note that no synchronization lock is held when {@link #acquire} is called as that would prevent an itemfrom being returned to the pool. The semaphore encapsulates the synchronization needed to restrict access to the pool, separately from any synchronization needed to maintain the consistency of the pool itself.
A semaphore initialized to one, and which is used such that it only has at most one permit available, can serve as a mutual exclusion lock. This is more commonly known as a binary semaphore, because it only has two states: one permit available, or zero permits available. When used in this way, the binary semaphore has the property (unlike many {@link Lock}implementations), that the "lock" can be released by a thread other than the owner (as semaphores have no notion of ownership). This can be useful in some specialized contexts, such as deadlock recovery.
The constructor for this class optionally accepts a fairness parameter. When set false, this class makes no guarantees about the order in which threads acquire permits. In particular, barging is permitted, that is, a thread invoking {@link #acquire} can be allocated a permit ahead of athread that has been waiting - logically the new thread places itself at the head of the queue of waiting threads. When fairness is set true, the semaphore guarantees that threads invoking any of the {@link #acquire() acquire} methods are selected to obtain permits in the order inwhich their invocation of those methods was processed (first-in-first-out; FIFO). Note that FIFO ordering necessarily applies to specific internal points of execution within these methods. So, it is possible for one thread to invoke {@code acquire} before another, but reach the ordering point afterthe other, and similarly upon return from the method. Also note that the untimed {@link #tryAcquire() tryAcquire} methods do nothonor the fairness setting, but will take any permits that are available.
Generally, semaphores used to control resource access should be initialized as fair, to ensure that no thread is starved out from accessing a resource. When using semaphores for other kinds of synchronization control, the throughput advantages of non-fair ordering often outweigh fairness considerations.
This class also provides convenience methods to {@link #acquire(int) acquire} and {@link #release(int) release} multiplepermits at a time. Beware of the increased risk of indefinite postponement when these methods are used without fairness set true.
Memory consistency effects: Actions in a thread prior to calling a "release" method such as {@code release()}happen-before actions following a successful "acquire" method such as {@code acquire()}in another thread. @since 1.5 @author Doug Lea
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 | |
| |
| |
| |
| |
| |
| |
| |
| |
| |