Skip to content
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 #1

Closed
tbu- opened this issue Mar 29, 2022 · 2 comments
Closed

Fairness #1

tbu- opened this issue Mar 29, 2022 · 2 comments

Comments

@tbu-
Copy link

tbu- commented Mar 29, 2022

Interesting project, got here from Reddit.

Some questions after reading the README:

  1. Is the mutex fair or eventually fair, i.e. does it guarantee that no thread can permanently starve another?
  2. What are the disadvantages and advantages compared to parking_lot? Quickly skimming the README of parking_lot suggests that their synchronization structures are also ≤ 1 word large, but even that information would be interesting in the README IMO.
@kprotty
Copy link
Owner

kprotty commented Mar 29, 2022

  1. No, it relies on the OS scheduler for fairness but tries to wake up threads in FIFO order to imply less unfair scheduling. See here for more. It looks like docs.rs isn't working atm and i'm not sure why.

  2. Advantages and disadvantages are listed in the README. It also does no heap allocations for the global table unlike in parking_lot (meaning it can be used in #[global_allocator] or whatever the lang attribute was). Run the benchmarks or use it locally to decide practical advantage.

@tbu-
Copy link
Author

tbu- commented Mar 29, 2022

Thanks for the answers.

I'm not that familiar with synchronization primitives and also wouldn't know how to benchmark them, but I understand the #[global_allocator] use case.

@tbu- tbu- closed this as completed Mar 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants