std: use block_current_task for thread parking on Hermit

[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.

Hermit has the block_current_task(_with_timeout)/wakeup_task syscalls for building custom synchronization primitives. block_current_task sets the thread's state to parked. The next yield to the scheduler will block until the task is woken up again. As Hermit does not use preemptive multitasking, this can be used to run userspace code (e.g. checking a condition) in between the syscalls.

This implementation uses an atomic state variable, similar to the futex parker, but instead of a PARKED state it stores the parking threads PID. The syscalls are used to emulate a futex operation:

1. Set the task state to blocked (block_current_task)
2. Check the state:
   a. if it was set to notified while changing the task state, "wakeup" the task, consume the token and return
   b. else sleep (yield_now)

CC @stlankes, @mkroening

[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 @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. 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? @kennytm

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

[bors]

@joboet: 🔑 Insufficient privileges: not in try users

[mkroening]

Thanks a lot, @joboet.

This looks very good to me! 👍

[stlankes]

Thanks a lot, @joboet.

[bors]

☔ The latest upstream changes (presumably #98545) made this pull request unmergeable. Please resolve the merge conflicts.

[joboet]

r? rust-lang/libs

[Mark-Simulacrum]

I am not sure this is convincing to me. My understanding (perhaps flawed, I'm definitely not an expert in this) is that relaxed doesn't guarantee that other threads will observe the new empty state; we need a release store that synchronizes with the other thread's acquire ordering in order to guarantee correct behavior here.

In general, I'm not sure that hermit should deviate from the pattern of the general unix thread parker implementation, which uses SeqCst ordering for all of these operations.

[m-ou-se]

My understanding (perhaps flawed, I'm definitely not an expert in this) is that relaxed doesn't guarantee that other threads will observe the new empty state; we need a release store that synchronizes with the other thread's acquire ordering in order to guarantee correct behavior here.

That's not correct. SeqCst or Release+Acquire also don't guarantee any other thread will directly observe the new value either. The specification only talks about ordering, not about timing. And even Relaxed guarantees a perfectly consistent ordering for all operations on the same atomic variable. Using stronger memory ordering only means that you can under some conditions guarantee that something that happened to another piece of memory is observable once an atomic store/change is observed, but is unrelated to when that change is observed in the first place.

[Mark-Simulacrum]

I'm also going to r? @m-ou-se who has put a lot more thought recently into this, since I suspect it'll be easy for me to miss something when reviewing this, and since I'm less than confident about the Relaxed memory ordering usage here.

[bors]

☔ The latest upstream changes (presumably #99251) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

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 @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. 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

[joboet]

Since Hermit now has futex syscalls, I'm going to close this PR, as Hermit can now share the futex parker used by other systems.