3 ms·
Thanks for this article. I feel the goal of a tool should be to make common patterns easy to represent: so "sprinkling async everywhere" only doesn't work beca
by samsquire 3y ago
Thanks for this article.
I feel the goal of a tool should be to make common patterns easy to represent: so "sprinkling async everywhere" only doesn't work because of some common desirable pattern not being easily representable in modern languages and gotchas of the languages.
I have a lightweight thread scheduler written in C and I communicate between threads with a lockless ringbuffer. IO threads do IO. I like the idea of event loops and libuv but I want parallelism.
I wanted to understand how to compile async/await so I wrote a multithreaded unrolled state machine in Java. Each async keyword sends to another thread. I haven't got it to send to a different thread each time to load balance, I need to spend more time on it.
task1:
handle1 = async task2();
handle2 = async task3();
handle3 = async task4();
// at this point, I want task2, task3, task4 to be going on in parallel ON DIFFERENT threads
await handle1;
await handle2;
await handle3;
I am designing a notation for concurrency and asynchronocity that is a directly a state machine. I need to write a specification and I'm working on a Java runtime. It looks like this. It's inspired by BNF and Prolog facts.
thread(s) = state1(yes) | send(message) | receive(message2);
thread(r) = state1(yes) | receive(message) | send(message2);
I am inspired by Pony lang, Go and Erlang but I think there's still lots of potential innovation in this space that could be had.
- sammko128 3y agoMaybe take a look at pi-calculus and session types if you're not familiar, the notation you're describing sounds very similar/related to that
- samsquire 3y agoThanks for your reply. I am coming from the perspective of states and behaviour. I have read about session types but my syntax is not inspired by them. Types are important and useful but I am more interested in the rigid parts of code that types data flow through otherwise known as control flow. I feel it's an ignored part of computer science. My goal is easy parallelism, asynchronocity and reactivity.
- gpderetta 3y agoTake a look at Cilk (a lightweight C first and C++ later dialect) that pretty much uses the same syntax you are using. Scheduling is done via workstealing. The Cilk papers in particular are very very good. They discuss the programming model, the compilation strategy, the scheduling algorithms and more. edit: this one for example http://supertech.csail.mit.edu/papers/cilk5.pdf http://supertech.csail.mit.edu/papers/cilk5.pdf
- pornel 3y agoRust explicitly has "Send" and "non-Send" futures that can execute either on any thread, or always on the same thread. Details depend on the executor, and you can roll your own if you want. This works in Rust: let thread_s = spawn(join!(state1(yes), send(message), receive(message2)); let thread_r = spawn(join!(state1(yes), receive(message), send(message2));