[Concurrency] choice of actor model

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
Detailed description: https://shamsimam.github.io/papers/
2014-agere-selector.pdf
Slides: https://shamsimam.github.io/papers/2014-agere-selector-slides.pdf

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@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
Slides: https://shamsimam.github.io/papers/2014-agere-selector-slides.pdf
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Do you have example communication patterns for the actor model/asynchronous
messaging context? It would be interesting to see if selectors could be
used to simplify programming such patterns.

Regards,
Shams.

···

On Sat, Aug 19, 2017 at 10:47 AM, Jonathan Hull <jhull@gbis.com> wrote:

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@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
Detailed description: https://shamsimam.github.io/papers/2014-agere-
selector.pdf
Slides: https://shamsimam.github.io/papers/2014-agere-selector-slides.pdf

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution