-
Notifications
You must be signed in to change notification settings - Fork 91
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
Adopt and expose exponential backoff spinning #29
Comments
Ah I finally get that For clarity, we can have methods
|
I'd just like to put a disclaimer: the current implementation of For reference, here is what Intel's TBB does: https://github.com/intel-tbb/intel-tbb/blob/master/include/tbb/tbb_machine.h#L349 |
Sure, but that's still strictly better than what we have now :) |
I'd just pull out 4 (for shifting) into a const for easy finding. Users that wish to tune for their own systems can use Cargo's |
Seems like a good idea to handle spinning more efficiently. |
parkinglot_core exposes it now, but the crate requires std and all. Maybe spin can copy that specific module sprinkling some conditional compilations around as suggested upthread. |
If I get the time, I plan to implement this next week. |
@Amanieu's parking_lot crate has a
SpinWait
module that implements exponential backoff. This would be a useful addition to the current implementation, and could also be exposed on its own. The latter might be useful when implementing other synchronization primitives that only need the spinning, and not the locking. There's been some discussion on this on the parking_lot issue tracker.The biggest hurdle to adoption is that
SpinWait
currently yields after spinning for a while, which wouldn't work withno_std
. As discussed on the parking_lot issue, this could be put behind a feature flag, or maybe even removed altogether and left to the users of the module.The text was updated successfully, but these errors were encountered: