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

Implement Once and generalize thread-local storage map #49

Merged
merged 1 commit into from
Sep 9, 2021

Conversation

jamesbornholt
Copy link
Member

Once is a synchronization primitive often used in a static variable to
ensure some initialization logic runs at most once in the execution of a
program. To ensure that we support this pattern, we implement a new
global storage map that is empied across executions, and use it to
ensure that a Once cell's state resets across test executions. This
also means that multiple Shuttle tests running concurrently (e.g., under
the cargo test runner with a default config) will see independent
instances of a static Once cell and be properly isolated from each
other.

The storage map shares common logic with the TLS map we already have, so
this PR factors that map out into a single abstraction.

In a future PR we'll use Once to implement lazy_static, which will also
store its values into the global storage map.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

src/sync/once.rs Outdated
}

trace!("won the call_once race for cell {:p}", self);
f();
Copy link
Member

Choose a reason for hiding this comment

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

The doc for Once says that if f panics here, the Once instance gets poisoned. In this version, Shuttle will just report a panic? Could you add a test for the "f panics" case?

Copy link
Member Author

@jamesbornholt jamesbornholt Sep 4, 2021

Choose a reason for hiding this comment

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

I ended up just implementing poisoning -- it's actually really easy because our Once uses a Mutex under the hood, and Mutex already supports poisoning. Added a test for it too.

src/sync/once.rs Outdated Show resolved Hide resolved
tests/basic/clocks.rs Outdated Show resolved Hide resolved
tests/basic/once.rs Outdated Show resolved Hide resolved
`Once` is a synchronization primitive often used in a static variable to
ensure some initialization logic runs at most once in the execution of a
program. To ensure that we support this pattern, we implement a new
global storage map that is empied across executions, and use it to
ensure that a `Once` cell's state resets across test executions. This
also means that multiple Shuttle tests running concurrently (e.g., under
the cargo test runner with a default config) will see independent
instances of a static Once cell and be properly isolated from each
other.

The storage map shares common logic with the TLS map we already have, so
this PR factors that map out into a single abstraction.

In a future PR we'll use Once to implement lazy_static, which will also
store its values into the global storage map.
once.call_once(|| init.store(me(), std::sync::atomic::Ordering::SeqCst));
let who_inited = init.load(std::sync::atomic::Ordering::SeqCst);
// should have inhaled the clock of the thread that inited the Once, but might also
// have inhaled the clocks of threads that we were racing with for initialization
Copy link
Member

Choose a reason for hiding this comment

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

I don't understand the second part of this comment. We are asserting here that this thread's clock is nonzero (causally depends on) only for (1) the thread that inited the Once, (2) itself, (3) the main thread.
Maybe just remove the second part of the comment?

Copy link
Member Author

Choose a reason for hiding this comment

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

We're asserting that the clock is non-zero for at least those three threads; we're saying nothing about the others. The comment is just to say why the check isn't stronger -- we might have learned something about threads other than those three depending on whether they raced for initialization or not.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, sorry. For some reason I was thinking of an equivalence; but it's just an implication.

@jorajeev jorajeev merged commit 7e10ce3 into awslabs:main Sep 9, 2021
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.

2 participants