I favor a wait-free concurrency model based on the `vat` from E language. Vats can be modeled very easily in Haskell, and in many other languages. I currently use such a vat model for my Haskell projects. I describe aspects of it at a few places:<div>
<br><div>* <a href="http://lambda-the-ultimate.org/node/4289#comment-65886">http://lambda-the-ultimate.org/node/4289#comment-65886</a> (vats and methods)</div><div>* <a href="http://lambda-the-ultimate.org/node/4325#comment-66645">http://lambda-the-ultimate.org/node/4325#comment-66645</a> (pipeline method calls)</div>
<div>* <a href="http://awelonblue.wordpress.com/2011/10/06/vat-model-for-rdp/">http://awelonblue.wordpress.com/2011/10/06/vat-model-for-rdp/</a> </div><div><br></div><div>Unfortunately, my code isn't generic. The vats I've implemented are specialized (i.e. via extra stages and queues) primarily for efficient processing of concurrent reactive dataflows.</div>
<div><br></div><div>Advantages of Vats:</div><div>* wait-free asynchronous IO, hence deadlock and starvation free</div><div>* first-class methods that help in many ways:</div><div>** distribute the dispatch burden (no need for a `main` switch statement)</div>
<div>** extensible (easy to add new methods without adjusting central code)</div><div>** transparent parallelization (calls may transparently invoke local or remote methods)</div><div>** securable (control distribution and parameter-types of methods)</div>
<div>** easily model code distribution (e.g. create a method with monad action parameters)</div><div>* simple state - variables local to each vat may be shared between methods</div><div>* coarse-grained `islands of consistency` are easy to reason about</div>
<div>* implicit batching between vats improves consistency AND efficiency</div><div>* easy to express incremental computation (as sequence of method calls)</div><div>* clean coarse-grained interaction with data-parallelism (e.g. spark parameters)</div>
<div><br></div><div>Technically, the vat consistency model is not `composable`. Instead, it works well based on coarse granularity and the natural limits of local reasoning - i.e. actual use-cases only interact with one or two other vats before they extend far enough that developers simply design assuming arbitrary ordering and potential interference. Developers can build ad-hoc consistency models atop vats easily enough. I use a temporal consistency model atop vats, which is composable, but is feasible for my reactive dataflow model primarily due to its updates being commutative. </div>
<div><br></div><div>That said, one should be careful about asserting transactions are composable. Transactions don't scale well as they compose, having greater opportunity for conflict, rework, starvation, priority inversion. Transactions also don't interact well with the real-world IO, such as continuous sensor streams or actuators. Despite the non-composability of vat semantics, they at least scale better than transactions. cf. <a href="http://awelonblue.wordpress.com/2011/07/05/transaction-tribulation/">http://awelonblue.wordpress.com/2011/07/05/transaction-tribulation/</a> </div>
<div><br></div><div>The recent work on Cloud Haskell takes a similar inspiration from E's vats. However, the focus of cloud haskell is different and consequently there are a lot of subtle but important differences between cloud haskell processes and my use of vats, e.g. regarding process identifiers, serializability requirements, etc.</div>
<div>* <a href="http://research.microsoft.com/~simonpj/papers/parallel/remote.pdf">http://research.microsoft.com/~simonpj/papers/parallel/remote.pdf</a> (cloud haskell)</div><div><br></div><div>Regards,</div><div><br></div>
<div>Dave</div><div><br></div><div><br></div><div><div class="gmail_quote">On Fri, Jan 13, 2012 at 9:24 PM, Joey Adams <span dir="ltr"><<a href="mailto:joeyadams3.14159@gmail.com">joeyadams3.14159@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In Haskell, sound logic and a great type system lead to elegant,<br>
composable code in a variety of domains, such as:<br>
<br>
* Expression evaluation<br>
* Parsing<br>
* Concurrent programming (thanks to STM)<br>
<br>
Asynchronous I/O is tricky. However, Haskell currently does little to<br>
alleviate the complexity (at least for me).<br>
<br>
How can we structure network protocol APIs so that they stack well<br>
(e.g. only lock once, rather than locking each layer's connection<br>
state)? How can we deal with I/O errors without having to think about<br>
them at every turn?<br>
<br>
For now, how can I structure my application's communication API so<br>
it's less messy to use?<br>
<br>
Thanks,<br>
- Joey<br>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div></div>