5 ms·
cf "It's time to embrace structured approaches to parallel, asynchronous, and concurrent programming." ~~ http://jnthn.net/papers/2015-yapcasia-concurrency.pdf#
by raiph 11y ago
cf "It's time to embrace structured approaches to parallel, asynchronous,
and concurrent programming." ~~ http://jnthn.net/papers/2015-yapcasia-concurrency.pdf#p=76 http://jnthn.net/papers/2015-yapcasia-concurrency.pdf#p=76
- PaulHoule 11y agoMore structured is probably going to look a bit like UML, Petri Nets, or RETE networks.
- vmorgulis 11y agoOr more abstract or declarative like Haskell or SQL...
- yxhuvud 11y agoIndeed. See the for example the Disruptor pattern for something that look like a (cyclefree) Petri Net.
- fizwhiz 11y agoCould you expound a little further on why the Disruptor pattern looks like a cycle-free Petri Net?
- yxhuvud 11y agoWell, the disruptor have a set of requests that are processed in parallel. Each request have a counter associated with it. Each request also have a step associated with it. A step can depend on an arbitrary number of earlier steps. This dependency based setup of steps can easily be mapped to petri form. Ok, maybe it isn't that close, but both are some kind of state machines that allow for arbitrary number of dependencies for each state and the mapping from a cycle free petri net to a disruptor is very trivial. Of course, the lack of cycles hobble the expressive power of the nets.
- nickpsecurity 11y agoLike Hansens's Concurrent Pascal, monitors, and distributed model? http://brinch-hansen.net/papers/ http://brinch-hansen.net/papers/ Or Eiffel's race-free SCOOP? Or Ada Ravenscar? Or ParaSail and Chapel custom made for it? Plenty of such work with proven results. Just little uptake of anything different before Haskell, Go, and Rust.