Concurrency: what measures does Rust take for ensuring secure concurrency? (big question - break this down!)

[andymeneely]

https://cwe.mitre.org/data/definitions/609 Double-Checked Locking
https://cwe.mitre.org/data/definitions/663 Use of a Non-reentrant Function in a Concurrent Context
https://cwe.mitre.org/data/definitions/820 Missing Synchronization
https://cwe.mitre.org/data/definitions/833 Deadlock
https://cwe.mitre.org/data/definitions/1058 Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element
https://cwe.mitre.org/data/definitions/1223 Race Condition for Write-Once Attributes

[MatthewFluet]

Regarding deadlock, neither the language nor the standard library prevents deadlock. The strong type system and ownership does allow abstractions of locks that could prevent deadlock (at the expense of some expressiveness) or could enforce a particular deadlock detection (at the expense of some performance), though both would require opt-in to use those abstractions and forgo using the deadlock possible std library locks.

[MatthewFluet]

Safe Rust does prevent Missing Synchronization; that's Rust's "Fearless Concurrency" guarantee (https://doc.rust-lang.org/book/ch16-03-shared-state.html). However, that only guarantees that are no (low-level, memory) race conditions; one does still need to be aware of higher-level, logical race conditions (e.g., fine-grained locks on a hash table will prevent dangling pointers, but don't automatically guarantee the atomicity of application-level logic, like a "move" operation that removes a key/value pair and re-inserts under a different key).

On the other hand, the CWE example of "Missing Synchronization" has to do with insufficient locking on stdout when a parent process forks a child process, for which Rust would not necessarily help. (It may be that the std library does better in that regard, e.g., with buffering, but it's a property of the implementation of the standard library, not the language.)