Uh oh!
There was an error while loading. Please reload this page.
std: Avoid usage of Once in Instant - #59676
Merged
Merged
Conversation
rust-highfive
commented
Apr 3, 2019
Contributor
r? @rkruppe (rust_highfive has picked a reviewer for you, use r? to override) |
alexcrichton
commented
Apr 3, 2019
MemberAuthor
r? @sfackler |
sfackler
commented
Apr 3, 2019
Member
@bors r+ |
bors
commented
Apr 3, 2019
Collaborator
📌 Commit 4ef32a4 has been approved by |
Centril added a commit
to Centril/rust
that referenced
this pull request
Apr 3, 2019
std: Avoid usage of `Once` in `Instant` This commit removes usage of `Once` from the internal implementation of time utilities on OSX and Windows. It turns out that we accidentally hit a deadlock today (rust-lang#59020) via events that look like: * A thread invokes `park_timeout` * Internally, only on OSX, `park_timeout` calls `Instant::elapsed` * Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize global timer data * Inside of `Once`, it attempts to `park` This means on the same stack frame, when there's contention, we're calling `park` from inside `park_timeout`, causing a deadlock! The solution implemented in this commit was to remove usage of `Once` and instead just do a small dance with atomics. There's no real need we need to guarantee that the global information is only learned once, only that it's only *stored* once. This implementation may have multiple threads invoke `mach_timebase_info`, but only one will store the global information which will amortize the cost for all other threads. A similar fix has been applied to windows to be uniform across our implementations, but looking at the code on Windows no deadlock was possible. This is purely just a consistency update for Windows and in theory a slightly leaner implementation. Closesrust-lang#59020
Centril
commented
Apr 3, 2019
Contributor
Failed in #59682 (comment), @bors r- |
This commit removes usage of `Once` from the internal implementation of time utilities on OSX and Windows. It turns out that we accidentally hit a deadlock today (rust-lang#59020) via events that look like: * A thread invokes `park_timeout` * Internally, only on OSX, `park_timeout` calls `Instant::elapsed` * Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize global timer data * Inside of `Once`, it attempts to `park` This means on the same stack frame, when there's contention, we're calling `park` from inside `park_timeout`, causing a deadlock! The solution implemented in this commit was to remove usage of `Once` and instead just do a small dance with atomics. There's no real need we need to guarantee that the global information is only learned once, only that it's only *stored* once. This implementation may have multiple threads invoke `mach_timebase_info`, but only one will store the global information which will amortize the cost for all other threads. A similar fix has been applied to windows to be uniform across our implementations, but looking at the code on Windows no deadlock was possible. This is purely just a consistency update for Windows and in theory a slightly leaner implementation. Closesrust-lang#59020
alexcrichton
commented
Apr 4, 2019
MemberAuthor
@bors: r=sfackler |
bors
commented
Apr 4, 2019
Collaborator
📌 Commit cb57484 has been approved by |
bors
commented
Apr 4, 2019
Collaborator
bors added a commit
that referenced
this pull request
Apr 4, 2019
std: Avoid usage of `Once` in `Instant` This commit removes usage of `Once` from the internal implementation of time utilities on OSX and Windows. It turns out that we accidentally hit a deadlock today (#59020) via events that look like: * A thread invokes `park_timeout` * Internally, only on OSX, `park_timeout` calls `Instant::elapsed` * Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize global timer data * Inside of `Once`, it attempts to `park` This means on the same stack frame, when there's contention, we're calling `park` from inside `park_timeout`, causing a deadlock! The solution implemented in this commit was to remove usage of `Once` and instead just do a small dance with atomics. There's no real need we need to guarantee that the global information is only learned once, only that it's only *stored* once. This implementation may have multiple threads invoke `mach_timebase_info`, but only one will store the global information which will amortize the cost for all other threads. A similar fix has been applied to windows to be uniform across our implementations, but looking at the code on Windows no deadlock was possible. This is purely just a consistency update for Windows and in theory a slightly leaner implementation. Closes#59020
bors
commented
Apr 4, 2019
Collaborator
☀️ Test successful - checks-travis, status-appveyor |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit removes usage of
Oncefrom the internal implementation oftime utilities on OSX and Windows. It turns out that we accidentally hit
a deadlock today (#59020) via events that look like:
park_timeoutpark_timeoutcallsInstant::elapsedInstant::elapsedon OSX we enter aOnceto initializeglobal timer data
Once, it attempts toparkThis means on the same stack frame, when there's contention, we're
calling
parkfrom insidepark_timeout, causing a deadlock!The solution implemented in this commit was to remove usage of
Onceand instead just do a small dance with atomics. There's no real need we
need to guarantee that the global information is only learned once, only
that it's only stored once. This implementation may have multiple
threads invoke
mach_timebase_info, but only one will store the globalinformation which will amortize the cost for all other threads.
A similar fix has been applied to windows to be uniform across our
implementations, but looking at the code on Windows no deadlock was
possible. This is purely just a consistency update for Windows and in
theory a slightly leaner implementation.
Closes#59020