A Naive Execution Model for Concurrency (github.com)
from cli345@programming.dev to programming_languages@programming.dev on 16 Apr 2024 16:27
https://programming.dev/post/12856421

This is just a very naive execution model for concurrency.

What do you think about it?

#programming_languages

threaded - newest

Corbin@programming.dev on 16 Apr 2024 20:44 collapse

Good work! This is a good start. These sorts of explanations build everybody’s understanding, including your own.

I’d like to mention E-order execution as a weaker alternative to seq. The idea is that sequential operations can be carried out in parallel if they don’t interact with each other’s memory locations. One way to do this is transactional memory, which has been implemented in hardware but is more common in software, hence software transactional memory or STM. That’s how Haskell does it. Another way is with message passing, as in Erlang or Elixir; each tiny process has its own private memory.

The name “E-order” comes from E, which had the ability to start multiple event loops. Erlang and Haskell only have one event loop, but E could give each loop its own private memory and CPU time; think thread-per-loop, but thousands of userspace loops scheduled onto a few threads with thread-per-core scheduling. In E and its descendants, each loop is called a “vat” and holds roughly one of your Frame Trees per vat. A vat takes “turns” and each turn is roughly like executing one of your Tree Branches. The trick is that a vat turn can use a native call stack since it is only one branch of the tree, and is amenable to standard JIT techniques.

cli345@programming.dev on 17 Apr 2024 11:03 collapse

Thank you very much for your feedback. 🙂