4 ms·

I’d very much like to see an accessible source on synchronous languages in general—a review paper maybe? So far I’ve only seen language-specific tutorials, wher

I’d very much like to see an accessible source on synchronous languages in general—a review paper maybe? So far I’ve only seen language-specific tutorials, where the nice things about the approach as such are liberally diluted with the specifics of the language and general programming knowledge. That said, from what I’ve seen Trio-style “structured concurrency” is somewhat less strict than the synchronous model: nurseries being tangible objects implies (1) you can spawn a dynamically-specified amount of cooperative threads, as you can just tell the nursery to spawn things in a loop; (2) you are not limited to strict nesting, as an ancestor thread can pass you a nursery closer to the root if it wishes. The result of the second point is that you can maintain a tree of responsibility for e.g. error propagation without having a stack discipline where a parent thread’s dynamic extent must encompass all of its children’s (though there must be an ancestor with such a property). Yes, that means you’re free to have a single catastrophically-crashing root nursery where everybody spawns whatever they want, but you’re also free not to (and in fact there’s a sort of capability discipline for that, to the extent that the host language encapsulates things).

jcelerier 4y ago
there's a few mentioned in my thesis's intro, 2.3 p.21 https://tel.archives-ouvertes.fr/tel-01947309/document https://tel.archives-ouvertes.fr/tel-01947309/document but it's by no means an exhaustive reference
vanderZwan 4y ago
There's an academic papers section on the website for Céu, which is a research language first and foremost: http://ceu-lang.org/publications.html http://ceu-lang.org/publications.html From the references of those papers it should be easy to find others, right? And yes, you're absolutely right that the synchronous model is more restrictive - most synchronous languages follow the GALS principle: "globally asynchronous, locally synchronous". One benefit of the synchronous model is that it can essentially be compiled to a finite state machine with a memory overhead of mere bytes per "trail" (the synchronous analogue of a thread - the code snipped above has one synchronous "main" trail that splits into two synchronous trails in the "par/or" section). The focus on this makes sense historically, since many synchronous languages were originally designed to target hard real-time embedded systems, where available memory is small, computational tasks are usually not very heavy, and the "asynchronous" part is interacting with the real world. But that also suggests that synchronous and asynchronous concurrency could complement each other with the right language design.

jcelerier 4y ago

there's a few mentioned in my thesis's intro, 2.3 p.21 https://tel.archives-ouvertes.fr/tel-01947309/document https://tel.archives-ouvertes.fr/tel-01947309/document but it's by no means an exhaustive reference

vanderZwan 4y ago

There's an academic papers section on the website for Céu, which is a research language first and foremost: http://ceu-lang.org/publications.html http://ceu-lang.org/publications.html From the references of those papers it should be easy to find others, right? And yes, you're absolutely right that the synchronous model is more restrictive - most synchronous languages follow the GALS principle: "globally asynchronous, locally synchronous". One benefit of the synchronous model is that it can essentially be compiled to a finite state machine with a memory overhead of mere bytes per "trail" (the synchronous analogue of a thread - the code snipped above has one synchronous "main" trail that splits into two synchronous trails in the "par/or" section). The focus on this makes sense historically, since many synchronous languages were originally designed to target hard real-time embedded systems, where available memory is small, computational tasks are usually not very heavy, and the "asynchronous" part is interacting with the real world. But that also suggests that synchronous and asynchronous concurrency could complement each other with the right language design.