Re:Show HN: Whirlwind – Async concurrent hashmap for Rust
by conradludgate on Tuesday November 05, 2024 @06:29PM
(#42056120)
By waking itself, the task goes back to the scheduler queue. It then returns pending, going back to the scheduler where it picks a new task. It will eventually pick the scheduled task again and poll the rwlock. This is a loop, even if it's a long-winded one, and is by all accounts spinning.
It really is not much different to a thread blocking on a loop, where the OS thread scheduler will pre-empt the thread, rescheduling it for later. In this case it's an async task instead of a thread, and cooperative instead of preemptive, but it's still unfair and not very effective use of scheduler resources
Re:Show HN: Whirlwind – Async concurrent hashmap for Rust
by dwattttt on Tuesday November 05, 2024 @06:42PM
(#42056201)
Oh my mistake. I wonder what the benchmarks would look like without the wake loop
Re:Show HN: Whirlwind – Async concurrent hashmap for Rust
by ibraheemdev on Tuesday November 05, 2024 @06:30PM
(#42056132)
> Every single Future you look at will look like this,
That's not true. A Future is supposed to schedule itself to be woken up again when it's ready. This Future schedules it to be woken immediately. Most runtimes, like Tokio, will put a Future that acts like this at the end of the run queue, so in practice it's not as egregious. However, it's unquestionably a spin lock, equivalent to back off with thread::yield.
- attempt to acquire an RWLock without blocking
- if it does, wake the task waiting for the lock
- if it doesn't, return "not ready yet"
The RWLock is straight from the standard lib; there's no loop and no spinning involved. Every single Future you look at will look like this, by specification they cannot block, only return "ready" (and wake the task), or return "not ready".