> On Sep 5, 2017, at 9:29 AM, Wallacy via swift-evolution > <[email protected]> wrote: > > "Actors are serial and exclusive, so this concurrent queue thing is not > relevant." > > Always? That is something i can't understand. The proposal actually cites the > "Intra-actor concurrency"
As a future extension yes, I don't think we should rush there ;) Dispatch has clearly failed at making intra-queue concurrency a first class citizen atm. > > "Also, int he QoS world, using reader writer locks or private concurrent > queues this way is not terribly great." > > This I understand, makes sense. > > "lastly for a simple writer like that you want dispatch_barrier_sync() not > async (async will create a thread and it's terribly wasteful for so little > work)." > > Yes, dispatch_barrier_sync makes more sense here... > > My point is: > > The proposal already define something like: actor var, in another words, "a > special kind of var", and " Improve Performance with Reader-Writer Access" is > not only a "special case" on concurrence world, but if make in the right way, > is the only reasonable way to use a "class variable" (actor is special class > right?) on multithreaded environment. If i'm not wrong (again) queues > (concurrent/serial) help the "lock hell" problem. > > It is only a thing to be considered before a final model is defined, thus > avoiding that in the future a big refactory is needed to solve something that > has not been considered now. > > Okay to start small, I'm just trying to better visualize what may be > necessary in the future to make sure that what has been done now will be > compatible. > > Thanks. > > > Em seg, 4 de set de 2017 às 16:06, Pierre Habouzit <[email protected] > <mailto:[email protected]>> escreveu: >> On Sep 4, 2017, at 7:27 AM, Wallacy via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> 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() >> >> Example: >> // ... >> _someManagerQueue = dispatch_queue_create("SomeManager", >> DISPATCH_QUEUE_CONCURRENT); >> // ... >> >> And then: >> >> - (id) getSomeArrayItem:(NSUInteger) index { >> id importantObj = NULL; >> dispatch_sync(_someManagerQueue,^{ >> id importantObj = [_importantArray objectAtIndex:index]; >> }); >> return importantObj; >> } >> - (void) removeSomeArrayItem:(id) object { >> dispatch_barrier_async(_someManagerQueue,^{ >> [_importantArray removeObject:object]; >> }); >> } >> - (void) addSomeArrayItem:(id) object { >> dispatch_barrier_async(_someManagerQueue,^{ >> [_importantArray addObject:object]; >> }); >> } >> >> That way you ensure that whenever you read an information (eg an array) all >> the "changes" have been made or are "waiting" . And every time you write >> an information, your program will not be blocked waiting for the operation >> to be completed. >> >> That way, if you use several threads, none will have to wait another to get >> any value unless one of them is "writing", which is right thing to do. >> >> 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. > > Actors are serial and exclusive, so this concurrent queue thing is not > relevant. > Also, int he QoS world, using reader writer locks or private concurrent > queues this way is not terribly great. > lastly for a simple writer like that you want dispatch_barrier_sync() not > async (async will create a thread and it's terribly wasteful for so little > work). > > We covered this subtleties in this year's WWDC GCD session. > > > -Pierre > > >> >> Em seg, 4 de set de 2017 às 08:20, Daniel Vollmer via swift-evolution >> <[email protected] <mailto:[email protected]>> escreveu: >> Hello, >> >> first off, I’m following this discussion with great interest, even though my >> background (simulation software on HPC) has a different focus than the >> “usual” paradigms Swift seeks to (primarily) address. >> >> > On 3. Sep 2017, at 19:26, Chris Lattner via swift-evolution >> > <[email protected] <mailto:[email protected]>> wrote: >> >> On Sep 2, 2017, at 11:09 PM, Pierre Habouzit <[email protected] >> >> <mailto:[email protected]>> wrote: >> >>> On Sep 2, 2017, at 12:19 PM, Pierre Habouzit <[email protected] >> >>> <mailto:[email protected]>> wrote: >> >>> >> >>> Is there a specific important use case for being able to target an actor >> >>> to an existing queue? Are you looking for advanced patterns where >> >>> multiple actors (each providing disjoint mutable state) share an >> >>> underlying queue? Would this be for performance reasons, for >> >>> compatibility with existing code, or something else? >> >> >> >> Mostly for interaction with current designs where being on a given bottom >> >> serial queue gives you the locking context for resources naturally >> >> attached to it. >> > >> > Ok. I don’t understand the use-case well enough to know how we should >> > model this. For example, is it important for an actor to be able to >> > change its queue dynamically as it goes (something that sounds really >> > scary to me) or can the “queue to use” be specified at actor >> > initialization time? >> >> I’m confused, but that may just be me misunderstanding things again. I’d >> assume each actor has its own (serial) queue that is used to serialize its >> messages, so the queue above refers to the queue used to actually process >> the messages the actor receives, correct? >> >> Sometimes, I’d probably make sense (or even be required to fix this to a >> certain queue (in the thread(-pool?) sense), but at others it may just make >> sense to execute the messages in-place by the sender if they don’t block so >> no context switch is incurred. >> >> > One plausible way to model this is to say that it is a “multithreaded >> > actor” of some sort, where the innards of the actor allow arbitrary number >> > of client threads to call into it concurrently. The onus would be on the >> > implementor of the NIC or database to implement the proper synchronization >> > on the mutable state within the actor. >> >> >> >> I think what you said made sense. >> > >> > Ok, I captured this in yet-another speculative section: >> > https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#intra-actor-concurrency >> > >> > <https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#intra-actor-concurrency> >> >> This seems like an interesting extension (where the actor-internal serial >> queue is not used / bypassed). >> >> >> Daniel. >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
