<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 4, 2017, at 7:53 AM, Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 4 sept. 2017 à 16:28, Wallacy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">I have a little question about the actors.</div><div class=""><br class=""></div><div class="">On WWDC 2012 Session 712 one of the most important tips (for me at least) was: Improve Performance with Reader-Writer Access </div><div class=""><br class=""></div><div class=""><div class=""><div class="">Basically:</div><div class="">• Use concurrent subsystem queue: DISPATCH_QUEUE_CONCURRENT</div></div>• Use synchronous concurrent “reads”: dispatch_sync()<br class="">• Use asynchronous serialized “writes”: dispatch_barrier_async()</div></div></div></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class="">[...]</blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class="">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.</div></div></div></blockquote><br class=""></div><div class="">I tend to believe that such read/write optimization could at least be implemented using the "Intra-actor concurrency" described by Chris Lattner at <a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#intra-actor-concurrency" class="">https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#intra-actor-concurrency</a>.</div></div></div></blockquote><div><br class=""></div>Right.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>