←back to thread

Futurelock: A subtle risk in async Rust

(rfd.shared.oxide.computer)
421 points bcantrill | 3 comments | 31 Oct 25 16:49 UTC | HN request time: 0.001s | source

This RFD describes our distillation of a really gnarly issue that we hit in the Oxide control plane.[0] Not unlike our discovery of the async cancellation issue[1][2][3], this is larger than the issue itself -- and worse, the program that hits futurelock is correct from the programmer's point of view. Fortunately, the surface area here is smaller than that of async cancellation and the conditions required to hit it can be relatively easily mitigated. Still, this is a pretty deep issue -- and something that took some very seasoned Rust hands quite a while to find.

[0] https://github.com/oxidecomputer/omicron/issues/9259

[1] https://rfd.shared.oxide.computer/rfd/397

[2] https://rfd.shared.oxide.computer/rfd/400

[3] https://www.youtube.com/watch?v=zrv5Cy1R7r4

Show context
levodelellis ◴[31 Oct 25 23:49 UTC] No.45777969[source]▶
In October alone I seen 5+ articles and comments about multi-threading and I don't know why

I always said if your code locks or use atomics, it's wrong. Everyone says I'm wrong but you get things like what's described in the article. I'd like to recommend a solution but there's pretty much no reasonable way to implement multi-threading when you're not an expert. I heard Erlang and Elixir are good but I haven't tried them so I can't really comment

replies(3): >>45777993 #>>45778558 #>>45779598 #
0x1ceb00da ◴[01 Nov 25 06:13 UTC] No.45779598[source]▶
> I always said if your code locks or use atomics, it's wrong.

Why atomics?

replies(1): >>45779724 #
1. levodelellis ◴[01 Nov 25 06:53 UTC] No.45779724[source]▶
People mess up the order all the time. When you mess up locks you get a deadlock, when you mess up an atomic you have items in the queue drop or processed twice, or some other weird behavior (waking up the wrong thread) you didn't expect. You just get hard to understand race conditions which are always a pain to debug

Just say no to atomics (unless they're hidden in a well written library)

replies(1): >>45781265 #
2. jstimpfle ◴[01 Nov 25 12:54 UTC] No.45781265[source]▶
People are messing up any number of things all the time. The more important question is, do you need to risk messing up in a particular situation? I.e. do you need multithreading? In many cases, for example HPC or GUI programming, the answer is yes, you need multithreading to avoid blocking and to get much higher performance.

With a little bit of experience and a bit of care, multithreading isn't _that_ hard. You just need to design for it. You can reduce the number of critical pieces.

replies(1): >>45786315 #
3. levodelellis ◴[01 Nov 25 23:08 UTC] No.45786315[source]▶
I completely disagree with you and I do write performance code (but not specifically HPC) and my current day job is highly async code with a GUI