Can Rust's `async`/`await` model the "synchronous concurrency" paradigm?

In the Hacker News discussion about async/await hitting stable, a commenter mentioned the "synchronous concurrency paradigm", as exemplified by the languages Esterel and Céu.

I have not yet had the time to read the Céu paper, but from what I can tell it actually looks somewhat similar to Rust's async/await semantics. I originally thought that the models might be isomorphic, i.e., that "trails" in Céu might be semantically equivalent to async fns in Rust, but the commenter said that Céu's ordering guarantees are fundamental to its model, whereas execution ordering is not required to be deterministic in Rust.

I haven't written a Reactor or Executor of my own, but I would expect it to be possible (perhaps even easy) to implement a Reactor that would ensure deterministic ordering by only marking a Future as ready to poll when it is the next polling operation's "turn". Alternatively, an Executor could ensure the ordering by simply halting execution entirely until the Future whose "turn" it is has been marked ready, and then polling only that Future.

I think this is an interesting avenue of exploration because, prior to hearing about synchronous concurrency, I was unaware of any prior art comparable to Rust's async design providing asynchronous semantics without requiring heap allocation and/or green threading. If Rust's async/await can be shown to model Céu's trails, then Céu/Esterel research results could be applied to Rust as well.

Would anyone be interested in helping me explore this connection and attempt to formalize the mapping from Rust's functionality to Céu's? Alternatively, does anyone know of any discrepancies in the models that make them incompatible?

4 Likes

Hello everyone! That commenter would be me. I'm basically one of the few Céu enthusiasts in the wild, although I admit not having actively programmed in it in a few years - my experimentation with it has been put on hold since the last time I experimented with my Arduino boards, basically.

Still, I have enough familiarity with it to hopefully be able to answer most questions about it (although I neither have the formal CS training nor any experience with Rust to really comment on deeper theory or the parallels with async fns in Rust). I have also pinged Francisco Sant'Anna, the creator of Céu, to check out this discussion.

For the record, the following papers are a bit more up-to-date compared to the 2013 PhD and may contain more useful information:

The Design and Implementation of the Synchronous Language Céu (TECS journal paper, 2017) - design and implementation of Céu, contrasting and comparing with Esterel

A Memory-Bounded, Deterministic and Terminating Semantics for the Synchronous Programming Language Céu - formal semantics of Céu, proofs for termination, determinism, and memory boundedness

As an alternative introduction, the 13 minute video on the main Céu website gives a very concrete overview of how programming in Céu works out in practice (I cannot link either because I'm a new user and am only allowed two links per post).

Anyway, in my personal experience Céu was a joy to play with - for certain concurrency problems I just felt like the code almost wrote itself, which I take as a sign that Céu might have the most intuitive way of mapping those particular problems to code. YMMV of course, but I'll hope you'll have as much fun exploring the language as I did.

3 Likes