You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes we want to change the capacities of semaphores after creating them.
It is possible that we implement a new command such as SET_CAPACITY.
But this approach introduces some complexity (e.g. how should we handle the case new capacity is smaller than current consumption).
Another solution is that a semaphore server does not manages the capacity of semaphore, and clients must specify the capacity in every acquire request.
This solution is simpler than SET_CAPACITY solution when clients always knows the current capacities.
The text was updated successfully, but these errors were encountered:
As we discussed offline, I recommend to keep the current semantics as static semaphores because semaphores are so popular that we cannot remove them.
Instead, add another kind of semaphores called dynamic semaphores.
Unlike static semaphores, dynamic semaphores do not have fixed capacities; instead, every acquire operation for them need to specify the current capacity of the semaphore.
This way, yrmcds can be used as a flexible resource limiter.
Sometimes we want to change the capacities of semaphores after creating them.
It is possible that we implement a new command such as
SET_CAPACITY
.But this approach introduces some complexity (e.g. how should we handle the case new capacity is smaller than current consumption).
Another solution is that a semaphore server does not manages the capacity of semaphore, and clients must specify the capacity in every
acquire
request.This solution is simpler than
SET_CAPACITY
solution when clients always knows the current capacities.The text was updated successfully, but these errors were encountered: