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

[joboet]

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]

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

[rust-highfive]

r? @m-ou-se

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

[joboet]

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

[kawadakk]

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]

[kawadakk]

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

The rest looks good to me.

[joboet]

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]

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]

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

[joboet]

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

[m-ou-se]

@bors r+

[bors]

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