[swift-evolution] [Concurrency] choice of actor model

Jonathan Hull jhull at gbis.com
Fri Aug 18 23:47:17 CDT 2017


The issue of a lack of ordering is one that actually comes up a lot in Swift, and we don’t have a good answer for it in general.  That might be something we want to take a deeper look at in the Swift 5 timeframe (at least to talk about options).  It would help more than just concurrency…

Thanks,
Jon


> On Aug 18, 2017, at 8:51 PM, Shams Imam via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> Disclaimer: this was work done during my graduate study. It was presented in front of an audience that included Gul Agha who appreciated the work.
> 
> The Actor model is great concurrency model to build on top of thanks to its data isolation and asynchronous message processing properties. However, lack of guarantees to control the order in which messages are processed by an actor makes implementing synchronization and coordination patterns difficult in the Actor model. Solutions to support such order in processing constraints may require the actor to buffer messages and resend the messages to itself until the message is processed. The resulting code is a petri-dish of code that intertwines both algorithmic logic and synchronization constraints.
> 
> I would encourage you to look into the Selector model which is an extension of the Actor model that allows an actor to have multiple mailboxes. These mailboxes can be enabled/disabled to control which message is processed next by the selector (in many ways this is similar to a select operation among multiple channels in Communicating Sequential Processes style programs). Enabling/disabling does not affect which messages are accepted at a mailbox. 
> 
> In essence, an actor is a selector with a single mailbox which is always enabled. Selectors simplify writing of synchronization and coordination patterns using actors such as:
> 
> a) 'synchronous' request-reply,
> b) join patterns in streaming applications,
> c) supporting priorities in message processing,
> d) variants of reader-writer concurrency, and
> e) producer-consumer with bounded buffer.
> 
> 
> Relevant links:
> http://dl.acm.org/citation.cfm?id=2687360 <http://dl.acm.org/citation.cfm?id=2687360>
> Detailed description: https://shamsimam.github.io/papers/2014-agere-selector.pdf <https://shamsimam.github.io/papers/2014-agere-selector.pdf>
> Slides: https://shamsimam.github.io/papers/2014-agere-selector-slides.pdf <https://shamsimam.github.io/papers/2014-agere-selector-slides.pdf>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170818/618d16f2/attachment.html>


More information about the swift-evolution mailing list