-
Notifications
You must be signed in to change notification settings - Fork 94
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
Implement a fairer locking strategy for a new mutex type #130
Conversation
Thanks for implementing this! I wonder whether this should be a separate implementation with the top-level |
Alright, I merged it out into its own file. Do you want me to add a feature to make the main |
Thanks, this is great. I'm hoping I'll get time to review this this weekend coming. Regarding feature flags, I might do some rearranging of things after this PR has been merged, so don't worry about that. |
Thank you!
I'd like to contribute to this crate more, so let me know if you want help with this "rearranging". |
@zesterer Have you had a chance to review this PR yet? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After spending some time reading through the implementation, I'm fairly confident in the code. Just a few more minor questions (I hope you understand: this is quite a large change, if not in terms of lines of code, in terms of 'number of users across the ecosystem').
(You probably want to squash this, by the way.) |
Thanks! |
* Implement a fairer locking strategy. * Merge out `FairMutex` into its own file. * Add feature documentation * Move increment after the check. * Fix MSRV build * Missed a couple
This PR implements a locking strategy for the
SpinMutex
type that uses eventual fairness, inspired by the one used in theasync-lock
crate. If a lock operation spins for a long period of time, it becomes a "starving" operation. When the mutex is eventually unlocked, starving locks are given precedence over non-starving locks. This is similar to less strict version ofTicketMutex
, in that it reduces contention in the worst cases.The only real downside of this strategy is that is uses an
AtomicUsize
instead of anAtomicBool
to keep track of the number of starving operations in addition to the lock status.