as far as i can tell there is no way to actually say “i want more/less of this” and influence the model’s behavior in any way 🙃

i would much rather talk *about* computers in public

🍄🍄‍🟫🍄

(mutex was used in these examples for simplicity but really, it’s anything that synchronizes in a LIFO way)

(the practical case in which we encountered this was not actually a mutex-qua-mutex but the queue of waiting senders for a MPSC queue, which disguised the underlying issue a bit more)

yeah, the underlying problem is inherent to a LIFO mutex. what i think is more novel here is just that it is a way that Rust’s async primitives give you a neat little way to have acquired a lock in a suspended coroutine without realizing you haven’t released the lock

i think Dave used the term “deadlock” a lot, and discussed how this is due in part to fairly queued locks, but he may not have specifically said “priority inversion” anywhere in the text 🤷‍♀️

the intent is not to claim to have discovered a totally novel category of bug but simply to be able to discuss how a priority inversion can result from the interaction of these commonly used constructs in a fairly non-obvious way

we agree that it is an instance of priority inversion! the name “futurelock” is intended to give a name to a *specific combination of Rust constructs that results in a priority inversion*. we felt this was useful so we could discuss this specific bug in the abstract while e.g. reviewing future code

‪they’re gonna be running a trillion simulations of my consciousness on a Dyson sphere made out of neutronium, and they’re all gonna just be trying to find an ebay listing for this thing that comes with the rails‬

“oh sick, this shit is gonna be so cheap on eBay some time after the Singularity!”

at least these say the name of a company on them