-
Notifications
You must be signed in to change notification settings - Fork 332
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
Remove spin lock from credentials #191
Conversation
Trying a model where slots of credentials exist, and updates move across the slots. Mutation detection is attempted via versioning of the credential changes.
Added debug status for the test to emit. Just switched to a single versioned credentials.
Added more comments to the creds provider to make the intention clearer. Simplified the usage of the object fields as part of removing an earlier design. Modified the tests to use the logger instead of std::cout
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.
Please address the comments before merging.
std::lock_guard<std::mutex> lock(update_mutex_); | ||
|
||
// | ||
// The ordering stores here is important. current_.updating_, and current_.version_ are atomics. |
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.
ordering of stores ?
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.
Fixed
} | ||
update_step(debug_stats.success_); | ||
return result; | ||
} while (true); |
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.
Is an infinite loop the right thing to do when the credential setter does not it correctly ? Or should we error out after some time ?
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.
Went back through my testing, and determined that devolving to the lock would provide similar performance. Made the changes for that now.
update_step(debug_stats.update_before_load_, debug_stats.retried_); | ||
continue; | ||
} | ||
std::uint64_t starting_version = current_.version_.load(); |
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.
should we be consistent in our use of atomic. If we use the atomic<T>::operator T
then we should use it everywhere instead of the equivalent .load
method unless we really want to specify memory order.
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.
Fixed
The credentials provided will now devolve to a full lock when an optimistic read fails. On my limited testing this happened ~0.007% of the times. Corrected some comments, and removed explicit uses of load()
Renamed the optimistic_read to try_optimistic_read to indicate that will update the argument passed to it.
Removed the spin lock from the credentials class. The spin lock was really expensive and problematic performance wise.
The new approach uses an optimistic read via an interlocked change process to allow the get method to detect a change and retry the load of the credentials.