-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fairness of semaphore #23
Comments
I wouldn't know of any (at least a simple-enough one). @taiki-e would you have some ideas?
Yeah, we should do that if @taiki-e doesn't have any ideas either. |
A fair semaphore would also be a requirement to use this in SQLx as otherwise it can easily lead to starvation at high contention. We previously learned this the hard way when we tried to use |
We could implement this in a similar way to |
I was looking for fairness guarantees of the
Semaphore
implementation and didn't find anything mentioned in the docs. After some digging I found thatevent_listener::Event
is used internally and documented as being fair.However looking at the implementation of
Semaphore::acquire
I can see that it is implemented as a loop callingtry_acquire
and creating aEventListener
in order to wait for a permit.async-lock/src/semaphore.rs
Lines 86 to 95 in 48a5b62
If I'm not mistaken it's possible that this code listens for an event and right after being woken another tasks snatches that permit away. This could lead to starvation where the tasks never manages to get a permit.
I think I've seen that exact behavior in some of my benchmarks where some workers hung forever causing timeouts and outliers.
I was wondering if there is a "easy" and correct way to make this implementation fair.
If that's out of scope for
async-lock
a small text in the documentation would be nice that it is not designed to be fair.The text was updated successfully, but these errors were encountered: