Concurrency, parallelism, async, multithreading is my favourite subject that I am interested in but I am not an expert.<p>Thank you for this article.<p>I think the ergonomics of modern programming languages for concurrency and parallelism is not there yet but I like structured concurrency.<p>In one of my projects I generate a dependency graph of work and then parallelise on all a node's egress edges in the graph. I just .join() threads in each node's thread on all ancestors of that node. This is how <a href="https://devops-pipeline.com/" rel="nofollow noreferrer">https://devops-pipeline.com/</a> works.<p>One approach to performance from parallelism, split/shard your data between threads and represent your concurrency AND parallelism as a tree of computation where leafs (leaves) of the tree never need to communicate until they complete leads to high performance because of Amdahls law and avoidance of synchronization during processing. Single core performance is fast and if you multithread it right you can get a performance boost. Single threaded can be faster than naïve multithreading due to synchronization overheads ( <a href="http://www.frankmcsherry.org/assets/COST.pdf" rel="nofollow noreferrer">http://www.frankmcsherry.org/assets/COST.pdf</a> )<p>My other approach is to create a syntax to represent multithreaded, concurrent and parallel state machines.<p>Kafka makes it fairly easy to parallelise pipelines and Go pipelines can be created, I just want to use a notation!<p>Here's my notation which I run on 2 threads:<p><pre><code> thread(s) = state1(yes) | send(message) | receive(message2);
thread(r) = state1(yes) | receive(message) | send(message2);
</code></pre>
This syntax is inspired by prolog facts. thread(s) and thread(r) are facts that the program waits for and need to be fired before the rest of the pipeline after the =. When state1(yes) is fired, the statemachine moves to the next state after the | pipe symbol. One thread sends send(message) a message and the other receives a message receive(message). You can also put multiple facts in each state line which provides asynchrony of multiple events joining into one state, kind of like multiple nodes connecting to a single node in a graph:<p><pre><code> order(orderno) checkout-received(orderno) = take-payment | save-order(orderno) | send-email-confirmation
</code></pre>
This waits for order(orderno) and checkout-received(orderno) separate events and then moves to the take-payment action.<p>I have a simple Java parser and runtime for this syntax. What I like about it is that it combines state machines, parallelism and asynchrony.