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

std: use an event-flag-based thread parker on SOLID #97140

Merged
merged 4 commits into from
Jun 26, 2022

Conversation

joboet
Copy link
Member

@joboet joboet commented May 18, 2022

Mutex and Condvar are being replaced by more efficient implementations, which need thread parking themselves (see #93740). Therefore, the generic Parker needs to be replaced on all platforms where the new lock implementation will be used, which, after #96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the μITRON specification, has event flags, which are a thread parking primitive very similar to Parker. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this Parker, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a WaitFlag structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API).

@kawadakk I assume you are the target maintainer? Could you test this for me?

@rust-highfive
Copy link
Collaborator

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label May 18, 2022
@rust-highfive
Copy link
Collaborator

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 18, 2022
@joboet
Copy link
Member Author

joboet commented May 18, 2022

I noticed this could be using a semaphore, which might be more efficient, as the system does not need to compare the bitflags...

Copy link
Contributor

@kawadakk kawadakk left a comment

Choose a reason for hiding this comment

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

The following code deadlocks under this implementation:

let thread0 = std::thread::current();
std::thread::spawn(move || {
    thread0.unpark();
});

std::thread::park_timeout(std::time::Duration::from_millis(50)); // <--- blocks indefinitely here

Reconstructed execution sequence:

st      Thread 0                            Thread 1 
--------------------------------------------------------------------------
 0      park_timeout:
-1          st.fetch_sub(1)     // 0
            twai_flg:
                [yield]
                                            unpark:
 1                                              st.swap(1)  // -1
                                                set_flg:
                                                    [wake up thread 0]

                [resume]

 0          st.swap(0)          // 1
            wai_flg
            [deadlock]

library/std/src/sys_common/thread_parker/wait_flag.rs Outdated Show resolved Hide resolved
library/std/src/sys_common/thread_parker/wait_flag.rs Outdated Show resolved Hide resolved
@m-ou-se m-ou-se added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 31, 2022
@joboet

This comment was marked as off-topic.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 4, 2022
Copy link
Contributor

@kawadakk kawadakk left a comment

Choose a reason for hiding this comment

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

The memory orderings can be relaxed to Acquire and Release like the futex-based implementation.

The rest looks good to me.

library/std/src/sys_common/thread_parker/wait_flag.rs Outdated Show resolved Hide resolved
library/std/src/sys_common/thread_parker/wait_flag.rs Outdated Show resolved Hide resolved
library/std/src/sys_common/thread_parker/wait_flag.rs Outdated Show resolved Hide resolved
library/std/src/sys_common/thread_parker/wait_flag.rs Outdated Show resolved Hide resolved
library/std/src/sys_common/thread_parker/wait_flag.rs Outdated Show resolved Hide resolved
library/std/src/sys_common/thread_parker/wait_flag.rs Outdated Show resolved Hide resolved
@joboet
Copy link
Member Author

joboet commented Jun 6, 2022

The memory orderings can be relaxed to Acquire and Release like the futex-based implementation.

Do we actually make any atomic ordering guarantees? It says so in the futex parker, but I can't find it in the documentation of unpark. Otherwise the ordering could be Relaxed.

@kawadakk
Copy link
Contributor

kawadakk commented Jun 7, 2022

It doesn't appear to be documented explicitly anywhere, but the common use cases of [un]park (alternating between calling park and checking an unblocking condition in a loop) and the past issues (e.g., #53366) seem to suggest that the requirement is to either form a synchronizes-with edge in token passing, or have a no-op unpark. If unpark blockingly consumed a token without forming a synchronizes-with edge, it would be completely useless, since it wouldn't propagate the change in the unblocking condition to the destination thread.

@joboet
Copy link
Member Author

joboet commented Jun 7, 2022

@kawadakk Ah, I understand now. Thank you for all the help!

Co-authored-by: Tomoaki Kawada <kawada@kmckk.co.jp>
@joboet
Copy link
Member Author

joboet commented Jun 17, 2022

ping @m-ou-se: I think all issues are fixed.

@m-ou-se
Copy link
Member

m-ou-se commented Jun 20, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Jun 20, 2022

📌 Commit caff723 has been approved by m-ou-se

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 20, 2022
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 20, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 24, 2022
std: use an event-flag-based thread parker on SOLID

`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see rust-lang#93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after rust-lang#96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API (which is unfortunately [broken](hermit-os/kernel#442), I think).

``@kawadakk`` I assume you are the target maintainer? Could you test this for me?
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 25, 2022
std: use an event-flag-based thread parker on SOLID

`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see rust-lang#93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after rust-lang#96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API (which is unfortunately [broken](hermit-os/kernel#442), I think).

```@kawadakk``` I assume you are the target maintainer? Could you test this for me?
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 25, 2022
std: use an event-flag-based thread parker on SOLID

`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see rust-lang#93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after rust-lang#96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API (which is unfortunately [broken](hermit-os/kernel#442), I think).

````@kawadakk```` I assume you are the target maintainer? Could you test this for me?
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 26, 2022
std: use an event-flag-based thread parker on SOLID

`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see rust-lang#93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after rust-lang#96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API).

`@kawadakk` I assume you are the target maintainer? Could you test this for me?
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 26, 2022
std: use an event-flag-based thread parker on SOLID

`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see rust-lang#93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after rust-lang#96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API).

``@kawadakk`` I assume you are the target maintainer? Could you test this for me?
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 26, 2022
std: use an event-flag-based thread parker on SOLID

`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see rust-lang#93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after rust-lang#96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API).

```@kawadakk``` I assume you are the target maintainer? Could you test this for me?
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 26, 2022
std: use an event-flag-based thread parker on SOLID

`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see rust-lang#93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after rust-lang#96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API).

````@kawadakk```` I assume you are the target maintainer? Could you test this for me?
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 26, 2022
…askrgr

Rollup of 11 pull requests

Successful merges:

 - rust-lang#97140 (std: use an event-flag-based thread parker on SOLID)
 - rust-lang#97295 ([rustc_parse] Forbid `let`s in certain places)
 - rust-lang#97743 (make const_err show up in future breakage reports)
 - rust-lang#97908 (Stabilize NonZero* checked operations constness.)
 - rust-lang#98297 (Transform help popup into a pocket menu)
 - rust-lang#98428 (macros: use typed identifiers in diag and subdiag derive)
 - rust-lang#98528 (Respect --color when building rustbuild itself)
 - rust-lang#98535 (Add regression test for generic const in rustdoc)
 - rust-lang#98538 (Add a ui test for issue rust-lang#91883)
 - rust-lang#98540 (Add regression test for rust-lang#87558)
 - rust-lang#98541 (Update `std::alloc::System` doc example code style)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit c348bea into rust-lang:master Jun 26, 2022
@rustbot rustbot added this to the 1.64.0 milestone Jun 26, 2022
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. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants