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

[Shams Imam via 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  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
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

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 
>  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

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

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

[Shams Imam via swift-evolution]

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