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

tough datastore: treat system_time as critical section and document #609

Merged
merged 4 commits into from
May 25, 2023

Conversation

webern
Copy link
Contributor

@webern webern commented Apr 21, 2023

Issue #, if available:

Closes #604
Documents which Datastore functions are thread safe and which one is not, see #602

Description of changes:

Adds documentation to the Datastore, moves the system_time function into the Datastore, and adds a lock guard to ensure thread safety of that function.

Testing

I tested this with our internal monitoring system for Bottlerocket repos and it worked.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

webern added 3 commits April 21, 2023 10:15
Add some documentation to the datastore in the
tough library. Importantly, we now document the
lack of thread safety in the reader function.
Because we are going to add another field to the
Datastore struct, we want to use named fields
instead of tuple syntax.

This commit has no changes to behavior.
Move the system_time function into the Datastore
object as a &self function.
Copy link
Contributor

@ecpullen ecpullen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

/// is protected by a lock guard to ensure thread safety.
pub(crate) fn system_time(&self) -> Result<DateTime<Utc>> {
// Treat this function as a critical section. This lock is not used for anything else.
let _lock = self.time_lock.write().map_err(|e| {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I always wondered if non-lexical lifetimes meant that this could potentially be dropped prior to the end of the lexical scope.

After reading a few resources, my understanding is that this will be dropped "at the end of its lifetime" which is currently the end of the scope. Possibly it's worth explicitly drop(_lock) at the end of the function to make accidental lifetime changes result in a compiler error.

Treat the datastore system_time function as a
critical section by giving it its own lock guard.
@webern webern merged commit f6b7053 into awslabs:develop May 25, 2023
@webern webern deleted the racey branch May 25, 2023 22:43
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

Successfully merging this pull request may close these issues.

Datastore: system_time should be a critical section
4 participants