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

park/park_timeout: prohibit spurious wakeups in next park #51290

Merged
merged 3 commits into from
Jun 29, 2018

Conversation

Pslydhh
Copy link
Contributor

@Pslydhh Pslydhh commented Jun 2, 2018


// The implementation currently uses the trivial strategy of a Mutex+Condvar
// with wakeup flag, which does not actually allow spurious wakeups.

Because does not actually allow spurious wakeups.
so we have let thread.inner.cvar.wait(m) in the loop to prohibit spurious wakeups.
but if notified after we locked, this notification doesn't be consumed, it return, the next park will consume this notification...this is also 'spurious wakeup' case, 'one unpark() wakeups two park()'.

We should improve this situation:
thread.inner.state.store(EMPTY, SeqCst);

should consume this notification, so prohibit spurious wakeups in next park
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 2, 2018
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:42] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:799: trailing whitespace
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:800: tab character
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:801: tab character
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:801: trailing whitespace
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:802: tab character
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:802: trailing whitespace
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:889: trailing whitespace
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:890: tab character
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:891: tab character
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:891: trailing whitespace
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:892: tab character
[00:04:43] tidy error: /checkout/src/libstd/thread/mod.rs:892: trailing whitespace
[00:04:44] some tidy checks failed
[00:04:44] 
[00:04:44] 
[00:04:44] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:44] 
[00:04:44] 
[00:04:44] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:44] Build completed unsuccessfully in 0:01:42
[00:04:44] Build completed unsuccessfully in 0:01:42
[00:04:44] Makefile:79: recipe for target 'tidy' failed
[00:04:44] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:088fccaa
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

remove trailing whitespace
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:53] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:54] tidy error: /checkout/src/libstd/thread/mod.rs:800: tab character
[00:04:54] tidy error: /checkout/src/libstd/thread/mod.rs:801: tab character
[00:04:54] tidy error: /checkout/src/libstd/thread/mod.rs:802: tab character
[00:04:54] tidy error: /checkout/src/libstd/thread/mod.rs:890: tab character
[00:04:54] tidy error: /checkout/src/libstd/thread/mod.rs:891: tab character
[00:04:54] tidy error: /checkout/src/libstd/thread/mod.rs:892: tab character
[00:04:55] some tidy checks failed
[00:04:55] 
[00:04:55] 
[00:04:55] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:55] 
[00:04:55] 
[00:04:55] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:55] Build completed unsuccessfully in 0:01:55
[00:04:55] Build completed unsuccessfully in 0:01:55
[00:04:55] make: *** [tidy] Error 1
[00:04:55] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:14db658c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@Mark-Simulacrum
Copy link
Member

r? @SimonSapin perhaps? Not sure who knows this code well.

@TimNN
Copy link
Contributor

TimNN commented Jun 12, 2018

Friendly triage ping, @SimonSapin / @rust-lang/libs, could you review that PR or assign someone more familiar with this code?

@SimonSapin
Copy link
Contributor

Sorry, I’m not confident about my understanding of this code. The winner of the git-shortlog lottery is…

r? @alexcrichton

(Unfortunately he’s away for the next few weeks.)

@pietroalbini pietroalbini added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 18, 2018
@pietroalbini pietroalbini added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 25, 2018
@alexcrichton
Copy link
Member

@bors: r+

Thanks for the PR @Pslydhh!

After thinking about this for a bit this does indeed seem like a valid optimization to do!

@bors
Copy link
Contributor

bors commented Jun 29, 2018

📌 Commit b352d2d has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 29, 2018
@bors
Copy link
Contributor

bors commented Jun 29, 2018

⌛ Testing commit b352d2d with merge 2eb6969...

bors added a commit that referenced this pull request Jun 29, 2018
park/park_timeout: prohibit spurious wakeups in next park

<pre><code>
// The implementation currently uses the trivial strategy of a Mutex+Condvar
// with wakeup flag, which does not actually allow spurious wakeups.
</pre></code>

Because does not actually allow spurious wakeups.
so we have let thread.inner.cvar.wait(m) in the loop to prohibit spurious wakeups.
but if notified after we locked, this notification doesn't be consumed, it return, the next park will consume this notification...this is also 'spurious wakeup' case, 'one unpark() wakeups two  park()'.

We should improve this situation:
`thread.inner.state.store(EMPTY, SeqCst);`
@bors
Copy link
Contributor

bors commented Jun 29, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 2eb6969 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants