4 ms·

Obviously no language can prevent race conditions. Race conditions are usually a flaw of protocol or api design. The whole point of 'fearless concurrency' is

Obviously no language can prevent race conditions. Race conditions are usually a flaw of protocol or api design. The whole point of 'fearless concurrency' is that you won't crash because of shared state.

ajross 6y ago
Yes, but there's a cost for that, which is something that's sort of at odds with Rust's design philosophy in other areas. Outlawing concurrent shared state means that every communication between two threads needs to be formatted as a "message" in whatever abstraction is in use. It needs to be copied, it needs to snapshot whatever data is needed to interpret it. You can't just set a flag and release the lock. And that's... a problem. Because a lot of code that actually wants concurrency in the same memory space is code that also wants high performance. And Rust serves these applications well in other areas, where "Just as fast as C" is true. But Rust isn't as fast as "C" here. It's demonstrably slower. Is that a good thing? I honestly don't know. It's just a hard problem. But you can't eliminate the idea of "shared locked memory" by fiat. It's a real requirement, and Rust has little to say about it in its standard library or (IIRC, though I'd have to go check) its memory model and locking primitives. It's sort of a no-mans land of "super unsafe outside the box" code. And that's a pity.
- deleted 6y ago
  [deleted]
- justinpombrio 6y ago
  > Outlawing concurrent shared state means that every communication between two threads needs to be formatted as a "message" in whatever abstraction is in use. > It's a real requirement, and Rust has little to say about it in its standard library So, I don't know much about concurrency, but you're looking for like, a Mutex, right? They're in the standard library and used all the time. https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html And RwLock, a variant on Mutex that allows either one writer or multiple concurrent readers: https://doc.rust-lang.org/stable/std/sync/struct.RwLock.html https://doc.rust-lang.org/stable/std/sync/struct.RwLock.html
  - lubesGordi 6y ago
    Yes! There's nothing weird about rust's synchronization on shared state. If you have a mutex, you can do what you want just like in c++. The mpsc::channel thing that gpp might be talking about is just a nice to have tool for sending data between threads. No one is forcing its use.
- pcwalton 6y ago
  > Outlawing concurrent shared state means that every communication between two threads needs to be formatted as a "message" in whatever abstraction is in use. It needs to be copied, it needs to snapshot whatever data is needed to interpret it. You can't just set a flag and release the lock. That isn't how Rust works. There are mutexes, condvars, atomics, etc. in the standard library. You don't need the unsafe keyword; go nuts with them.
pjmlp 6y ago
If the shared state is via shared memory IPC, you can only protect the Rust side, and have zero guarantees about its current state. It requires the use of unsafe on the Rust side, and you better code it very carefully.
johnisgood 6y ago
I think Ada/SPARK comes pretty close in my opinion. How come it does not get as much attention as Rust when it comes to safety? To stay on topic: https://docs.adacore.com/spark2014-docs/html/ug/en/source/concurrency.html#protected-types-and-protected-objects https://docs.adacore.com/spark2014-docs/html/ug/en/source/co... and https://blog.adacore.com/gnat-community-2020-is-here https://blog.adacore.com/gnat-community-2020-is-here are worth a read. Additionally: > The Ada concurrency model is based on the notion of task, a unit of concurrency that represents an independent thread of control. All, the tasks and the mechanisms for inter-task communication and synchronization, are introduced at language level in order to allow building safer programs. As an illustration, Ada 95 introduced protected objects to allow controlling how data is accessed, thus eliminating race conditions. Additionally, in 1997, Burns et al. introduced the Ravenscar profile, a subset of the Ada programming language that allows high integrity applications to be analyzed for their timing properties by pursuing three main goals: (1) ensuring predictable execution, (2) simplifying the runtime support, and (3) eliminating constructs with high overhead. The limitations imposed by the Ravenscar profile have an inevitable impact in the complexity of correctness analyses, e.g. tasks can only communicate through shared objects (tasks entries are not allowed, so the rendezvous mechanism cannot be used), tasks are assumed to be non-terminating, and tasks and protected objects cannot be dynamically allocated. > Along the same lines, SPARK, a language that subsets Ada to enable the formal verification of programs, eliminates race conditions by forcing any global object referenced from a task to be marked as Part Of that task, or be a synchronized object. I think I have a comment about Ada's concurrency where I get into it in more detail (IIRC).
- pjmlp 6y ago
  Because GNAT is the only free compiler out of surviving 5 or so, and even it has had some controversy in the past regarding GCC and Pro version, on a day and age, where many don't want to pay for compilers, which unfortunately are on corporate price levels in what concerns Ada offerings. Then Pascal/Algol syntax is not cool, so you always get a bit of push back on a world that now breaths curly brackets. However NVidia has recently chosen Ada/SPARK for their security critical firmware, so there's that.
- mratsim 6y ago

ajross 6y ago

Yes, but there's a cost for that, which is something that's sort of at odds with Rust's design philosophy in other areas. Outlawing concurrent shared state means that every communication between two threads needs to be formatted as a "message" in whatever abstraction is in use. It needs to be copied, it needs to snapshot whatever data is needed to interpret it. You can't just set a flag and release the lock. And that's... a problem. Because a lot of code that actually wants concurrency in the same memory space is code that also wants high performance. And Rust serves these applications well in other areas, where "Just as fast as C" is true. But Rust isn't as fast as "C" here. It's demonstrably slower. Is that a good thing? I honestly don't know. It's just a hard problem. But you can't eliminate the idea of "shared locked memory" by fiat. It's a real requirement, and Rust has little to say about it in its standard library or (IIRC, though I'd have to go check) its memory model and locking primitives. It's sort of a no-mans land of "super unsafe outside the box" code. And that's a pity.

deleted 6y ago
[deleted]
justinpombrio 6y ago
> Outlawing concurrent shared state means that every communication between two threads needs to be formatted as a "message" in whatever abstraction is in use. > It's a real requirement, and Rust has little to say about it in its standard library So, I don't know much about concurrency, but you're looking for like, a Mutex, right? They're in the standard library and used all the time. https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html And RwLock, a variant on Mutex that allows either one writer or multiple concurrent readers: https://doc.rust-lang.org/stable/std/sync/struct.RwLock.html https://doc.rust-lang.org/stable/std/sync/struct.RwLock.html
- lubesGordi 6y ago
  Yes! There's nothing weird about rust's synchronization on shared state. If you have a mutex, you can do what you want just like in c++. The mpsc::channel thing that gpp might be talking about is just a nice to have tool for sending data between threads. No one is forcing its use.
pcwalton 6y ago
> Outlawing concurrent shared state means that every communication between two threads needs to be formatted as a "message" in whatever abstraction is in use. It needs to be copied, it needs to snapshot whatever data is needed to interpret it. You can't just set a flag and release the lock. That isn't how Rust works. There are mutexes, condvars, atomics, etc. in the standard library. You don't need the unsafe keyword; go nuts with them.

pjmlp 6y ago

If the shared state is via shared memory IPC, you can only protect the Rust side, and have zero guarantees about its current state. It requires the use of unsafe on the Rust side, and you better code it very carefully.

johnisgood 6y ago

I think Ada/SPARK comes pretty close in my opinion. How come it does not get as much attention as Rust when it comes to safety? To stay on topic: https://docs.adacore.com/spark2014-docs/html/ug/en/source/concurrency.html#protected-types-and-protected-objects https://docs.adacore.com/spark2014-docs/html/ug/en/source/co... and https://blog.adacore.com/gnat-community-2020-is-here https://blog.adacore.com/gnat-community-2020-is-here are worth a read. Additionally: > The Ada concurrency model is based on the notion of task, a unit of concurrency that represents an independent thread of control. All, the tasks and the mechanisms for inter-task communication and synchronization, are introduced at language level in order to allow building safer programs. As an illustration, Ada 95 introduced protected objects to allow controlling how data is accessed, thus eliminating race conditions. Additionally, in 1997, Burns et al. introduced the Ravenscar profile, a subset of the Ada programming language that allows high integrity applications to be analyzed for their timing properties by pursuing three main goals: (1) ensuring predictable execution, (2) simplifying the runtime support, and (3) eliminating constructs with high overhead. The limitations imposed by the Ravenscar profile have an inevitable impact in the complexity of correctness analyses, e.g. tasks can only communicate through shared objects (tasks entries are not allowed, so the rendezvous mechanism cannot be used), tasks are assumed to be non-terminating, and tasks and protected objects cannot be dynamically allocated. > Along the same lines, SPARK, a language that subsets Ada to enable the formal verification of programs, eliminates race conditions by forcing any global object referenced from a task to be marked as Part Of that task, or be a synchronized object. I think I have a comment about Ada's concurrency where I get into it in more detail (IIRC).

pjmlp 6y ago
Because GNAT is the only free compiler out of surviving 5 or so, and even it has had some controversy in the past regarding GCC and Pro version, on a day and age, where many don't want to pay for compilers, which unfortunately are on corporate price levels in what concerns Ada offerings. Then Pascal/Algol syntax is not cool, so you always get a bit of push back on a world that now breaths curly brackets. However NVidia has recently chosen Ada/SPARK for their security critical firmware, so there's that.
mratsim 6y ago