undefined | Better HN

0 pointsTheNorthman6y ago0 comments

Continuing from the same Wikipedia page, it mentions three levels of thread safety. Rust support all of them, and can guarantee them at compile time:

> _Thread safe_: Implementation is guaranteed to be free of race conditions when accessed by multiple threads simultaneously.

> _Conditionally safe_: Different threads can access different objects simultaneously, and access to shared data is protected from race conditions.

> _Not thread safe_: Data structures should not be accessed simultaneously by different threads.

0 comments

2 comments · 1 top-level

mratsim6y ago· 1 in thread

It does not though? How does Rust proves that your implementation of a Peterson's lock algorithm[1] or Lamport's Bakery algorithm[2] is:

- Deadlock-free

- Live-lock free

- Free of data races

Second, how does Rust proves that you are correctly using the relaxed, acquire and release atomics so that your channel implementation is free of data races?

You can use Loom[3] but this is guarantee is certainly not provided by the compiler.

In short, Rust compiler only addresses memory issues by flat out preventing memory sharing. However, someone has to write those sharing/synchronizing data structures (Channels, Event Bus, Concurrent Hash-Table, ...) and those people have no tools that help them navigate the significant complexity of multithreading that go beyond memory and lifetime bugs.

[1]: https://en.wikipedia.org/wiki/Peterson%27s_algorithm#The_alg...

[2]: https://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm

[3]: https://github.com/tokio-rs/loom

TheNorthmanOP6y ago

That's my mistake. I confused data races and general race conditions, sorry about that :).

j / k navigate · click thread line to collapse