Public Member Functions | |
this (int permits, bool fair=false) | |
void | acquire (int permits=1) |
bool | tryAcquire (int permits=1) |
bool | tryAcquire (long timeout, TimeUnit unit, int permits=1) |
void | release (int permits=1) |
int | availablePermits () |
int | drainPermits () |
bool | isFair () |
bool | hasQueuedThreads () |
int | getQueueLength () |
char[] | toString () |
Protected Member Functions | |
void | reducePermits (int reduction) |
Thread[] | getQueuedThreads () |
Private Attributes | |
Sync | sync |
Classes | |
class | FairSync |
class | NonfairSync |
class | Sync |
Conceptually, a semaphore maintains a set of permits. Each acquire blocks if necessary until a permit is available, and then takes it. Each release adds a permit, potentially releasing a blocking acquirer. However, no actual permit objects are used; the Semaphore
just keeps a count of the number available and acts accordingly.
Semaphores are often used to restrict the number of threads than can access some (physical or logical) resource. For example, here is a class that uses a semaphore to control access to a pool of items:
class Pool { private const MAX_AVAILABLE = 100; private Semaphore available; this() { available = new Semaphore(MAX_AVAILABLE, true); used = new bool[MAX_AVAILABLE]; } Object getItem() { available.acquire(); return getNextAvailableItem(); } void putItem(Object x) { if (markAsUnused(x)) available.release(); } // Not a particularly efficient data structure; just for demo protected Object[] items; // whatever kinds of items being managed protected bool[] used; protected synchronized Object getNextAvailableItem() { for (int i = 0; i < MAX_AVAILABLE; ++i) { if (!used[i]) { used[i] = true; return items[i]; } } return null; // not reached } protected synchronized bool markAsUnused(Object item) { for (int i = 0; i < MAX_AVAILABLE; ++i) { if (item == items[i]) { if (used[i]) { used[i] = false; return true; } else return false; } } return false; } }
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 acquire is called as that would prevent an item from 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 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 acquire can be allocated a permit ahead of a thread that has been waiting. When fairness is set true, the semaphore guarantees that threads invoking any of the acquire() methods are allocated permits in the order in which 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.
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 acquire and release multiple permits at a time. Beware of the increased risk of indefinite postponement when these methods are used without fairness set true.
Definition at line 137 of file Semaphore.d.
|
Creates a
Definition at line 237 of file Semaphore.d. References sync. |
|
Acquires the given number of permits from this semaphore, blocking until all are available. Acquires the given number of permits, if they are available, and returns immediately, reducing the number of available permits by the given amount. If insufficient permits are available then the current thread becomes disabled for thread scheduling purposes and lies dormant until some other thread invokes one of the release methods for this semaphore, the current thread is next to be assigned permits and the number of available permits satisfies this request.
Definition at line 260 of file Semaphore.d. References AbstractLock::acquireShared(), and sync. |
|
Acquires the given number of permits from this semaphore, only if all are available at the time of invocation.
Acquires the given number of permits, if they are available, and returns immediately, with the value
If insufficient permits are available then this method will return immediately with the value
Even when this semaphore has been set to use a fair ordering policy, a call to
Definition at line 291 of file Semaphore.d. References Semaphore::Sync::nonfairTryAcquireShared(), and sync. |
|
Acquires the given number of permits from this semaphore, if all become available within the given waiting time.
Acquires the given number of permits, if they are available and returns immediately, with the value If insufficient permits are available then the current thread becomes disabled for thread scheduling purposes and lies dormant until one of three things happens:
If the permits are acquired then the value
If the specified waiting time elapses then the value
Definition at line 329 of file Semaphore.d. References sync, toNanos(), and AbstractLock::tryAcquireSharedNanos(). |
|
Releases the given number of permits, returning them to the semaphore. Releases the given number of permits, increasing the number of available permits by that amount. If any threads are blocking trying to acquire permits, then the one that has been waiting the longest is selected and given the permits that were just released. If the number of available permits satisfies that thread's request then that thread is re-enabled for thread scheduling purposes; otherwise the thread continues to wait. If there are still permits available after the first thread's request has been satisfied, then those permits are assigned to the next waiting thread. If it is satisfied then it is re-enabled for thread scheduling purposes. This continues until there are insufficient permits to satisfy the next waiting thread, or there are no more waiting threads. There is no requirement that a thread that releases a permit must have acquired that permit by calling acquire. Correct usage of a semaphore is established by programming convention in the application.
Definition at line 359 of file Semaphore.d. References AbstractLock::releaseShared(), and sync. |
|
Returns the current number of permits available in this semaphore. This method is typically used for debugging and testing purposes.
Definition at line 370 of file Semaphore.d. References Semaphore::Sync::getPermits(), and sync. |
|
Acquire and return all permits that are immediately available.
Definition at line 378 of file Semaphore.d. References Semaphore::Sync::drainPermits(), and sync. |
|
Shrinks the number of available permits by the indicated reduction. This method can be useful in subclasses that use semaphores to track resources that become unavailable. This method differs from
Definition at line 390 of file Semaphore.d. References Semaphore::Sync::reducePermits(), and sync. |
|
Returns true if this semaphore has fairness set true.
Definition at line 400 of file Semaphore.d. References sync. |
|
Queries whether any threads are waiting to acquire. Note that because cancellations may occur at any time, a
Definition at line 414 of file Semaphore.d. References AbstractLock::hasQueuedThreads(), and sync. |
|
Returns an estimate of the number of threads waiting to acquire. The value is only an estimate because the number of threads may change dynamically while this method traverses internal data structures. This method is designed for use in monitoring of the system state, not for synchronization control.
Definition at line 427 of file Semaphore.d. References sync. |
|
Returns a collection containing threads that may be waiting to acquire. Because the actual set of threads may change dynamically while constructing this result, the returned collection is only a best-effort estimate. The elements of the returned collection are in no particular order. This method is designed to facilitate construction of subclasses that provide more extensive monitoring facilities.
Definition at line 441 of file Semaphore.d. References sync. |
|
Returns a string identifying this semaphore, as well as its state. The state, in brackets, includes the String "Permits =" followed by the number of permits.
Definition at line 452 of file Semaphore.d. References Semaphore::Sync::getPermits(), and sync. |
|
All mechanics via AbstractLock subclass Definition at line 139 of file Semaphore.d. Referenced by acquire(), availablePermits(), drainPermits(), getQueuedThreads(), getQueueLength(), hasQueuedThreads(), isFair(), reducePermits(), release(), this(), toString(), and tryAcquire(). |