> On Sep 4, 2017, at 7:53 AM, Gwendal Roué via swift-evolution > <swift-evolution@swift.org> wrote: > > >> Le 4 sept. 2017 à 16:28, Wallacy via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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>.
Right. > 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. Right. A further concern is that while it is possible to encode reader/writer concerns into the type system, it makes the system as a whole more complicated. I’m really trying to start with a intentionally very simple model, because the following years of feature creep will provide ample opportunity to look at the problems that occur in practice and address them. Preemptively trying to solve problems that may not manifest in practice (or occur in different ways) can lead to designing solutions for problems that don’t exist or designing the wrong solution. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
