4 ms·

> The vast majority of production failures in kernel code are due to race conditions and other timing-specific issues, which unit tests are extremely poor at re

> The vast majority of production failures in kernel code are due to race conditions and other timing-specific issues, which unit tests are extremely poor at reproducing in a way that mimics how the code is used in real life. Is this not due to the legacy of a language that allows race conditions? Take Loom [1] in Rust which is a tool to test your concurrency primitives, ensuring that deterministically all interleavings are tested and verified to be sound. Then, when you expose a safe interface, you know that the only potential issues you have are user logic errors or not covering the entire problem space with your tests. https://docs.rs/loom/latest/loom/ https://docs.rs/loom/latest/loom/

bakugo 4y ago
I'm surprised that I had to scroll this far down to find a Rust fanatic complaining about C.
- Gwypaas 4y ago
  I complain similarly about writing deeply multithreaded code with synchronized data structures in Java, Go or whatever. It's a nightmare the day you want to refactor anything and have to keep the entire implicit state in your mind to make sure you don't trip over yourself.
Cacti 4y ago
Race conditions are not limited to those “caused by language”, whatever that means.
IgorPartola 4y ago
You also interact with hardware. An RC-safe language does nothing when you suddenly realize there is an RC baked into the disk driver you are using and if you send it specific commands in a specific order too fast it does something unexpected.
- Gwypaas 4y ago
  Yes, that widens the problem space considerably, especially if it depends on the rate of access or something similarly non-deterministic. But you're still fundamentally testing interleavings through a synchronization library. Still, reducing the problem space to such problems instead of any time you reach for atomics or a mutex, I imagine, removes the majority of bugs, so lets not throw the baby out with the bathwater because it's not perfect.

bakugo 4y ago

I'm surprised that I had to scroll this far down to find a Rust fanatic complaining about C.

Gwypaas 4y ago
I complain similarly about writing deeply multithreaded code with synchronized data structures in Java, Go or whatever. It's a nightmare the day you want to refactor anything and have to keep the entire implicit state in your mind to make sure you don't trip over yourself.

Cacti 4y ago

Race conditions are not limited to those “caused by language”, whatever that means.

IgorPartola 4y ago

You also interact with hardware. An RC-safe language does nothing when you suddenly realize there is an RC baked into the disk driver you are using and if you send it specific commands in a specific order too fast it does something unexpected.

Gwypaas 4y ago
Yes, that widens the problem space considerably, especially if it depends on the rate of access or something similarly non-deterministic. But you're still fundamentally testing interleavings through a synchronization library. Still, reducing the problem space to such problems instead of any time you reach for atomics or a mutex, I imagine, removes the majority of bugs, so lets not throw the baby out with the bathwater because it's not perfect.