[rust-dev] Why focus on single-consumer message passing?

Daniel Micay danielmicay at gmail.com
Sat Jan 25 03:56:08 PST 2014


On Sat, Jan 25, 2014 at 6:44 AM, Lee Braiden <leebraid at gmail.com> wrote:
> On 25/01/14 10:48, Daniel Micay wrote:
>>
>> I doubt it's really any easier to avoid race conditions with channels as
>> opposed to concurrent data structures, whether they are persistent or
>> mutable. Keep in mind that Rust won't let you have data races whether or not
>> you are sharing data.
>
>
> With messages sent on channels, you're encoding a message-based protocol (by
> definition) and something at least similar to state machines for each
> receiver task.  IF the compiler understands that, then you can, potentially,
> add additional, strong, static checking, and much more helpful diagnostics.

You can say the exact same thing about other concurrent data
structures. It's easy enough to expose a slow concurrent hash table
API via message passing, so it's obviously no different...

> You ARE sacrificing flexibility by working within that framework, but I
> think the general idea is that most (all?) parallel jobs CAN be well
> modelled by a message-passing protocol, and so the "extra flexibility" is
> really just "ability to screw it up, without a framework".  If you think
> about it, this is really just encapsulation of concurrent data behind
> accessor methods: the alternative is to randomly access shared data at any
> time, which is clearly more risky (not JUST because of data races, but also
> because of protocol violations / state-machine bugs), although it can
> obviously be done equally well by hand, if you're very careful, and Rust's
> data ownership will help, of course.

It's no harder to screw up outside of message passing. You're not
offering any valid points against concurrent data structures.

> not JUST because of data races, but also because of protocol violations / state-machine bugs

Again, there is no risk of data races in Rust. There is also no
increased risk in violating a protocol, as you can represent the same
concepts with both and the compiler isn't going to be able to gain
increased information from a queue used for message passing over a
hash table.

You could have support for building protocols that are provably free
of data races, but there's no reason it has to be restricted to a FIFO
queue and it will be unable to prove more when you're using the FIFO
queue in an unrestricted fashion.

> The main worry I have with message-passing/actor architectures is
> performance, but that's exactly why the language should understand the
> protocols and be able to compile a: send(b) b: receive(b); total += b down
> to just total += b, if/when that's appropriate.

These are never going to be language features and compiler magic like
this simply isn't very realistic. It's quite ridiculous to talk about
designing based on a fantasy world with a sufficiently smart compiler
when you're talking about a language like Rust exposing the details of
memory layout, ownership and lifetimes.


More information about the Rust-dev mailing list