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
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?
threaded - newest
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.
Thank you very much for your feedback. 🙂