[swift-evolution] [Concurrency] async/await + actors

[Gwendal Roué]

> Le 4 sept. 2017 à 16:28, Wallacy via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Hello,
> 
> I have a little question about the actors.
> 
> On WWDC 2012 Session 712 one of the most important tips (for me at least) was: Improve Performance with Reader-Writer Access
> 
> Basically:
> • Use concurrent subsystem queue: DISPATCH_QUEUE_CONCURRENT
> • Use synchronous concurrent “reads”: dispatch_sync()
> • Use asynchronous serialized “writes”: dispatch_barrier_async()
> 
> [...]
> 
> With this will it be composed using actors? I see a lot of discussion about using serial queues, and I also have not seen any mechanism similar to dispatch_barrier_async being discussed here or in other threads.

I tend to believe that such read/write optimization could at least be implemented using the "Intra-actor concurrency" described by Chris Lattner at https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#intra-actor-concurrency <https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#intra-actor-concurrency>.

But you generally ask the question of reader vs. writer actor methods, that could be backed by dispatch_xxx/dispatch_barrier_xxx. I'm not sure it's as simple as mutating vs. non-mutating. For example, a non-mutating method can still cache the result of some expensive computation without breaking the non-mutating contract. Unless this cache is itself a read/write-safe actor, such non-mutating method is not a real reader method.

That's a very interesting topic, Wallacy!

Gwendal

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