Fair enough! Tranks! Em ter, 5 de set de 2017 às 13:48, Pierre Habouzit <[email protected]> escreveu:
> 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]> > escreveu: > >> On Sep 4, 2017, at 7:27 AM, Wallacy via swift-evolution < >> [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]> 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]> wrote: >>> >> On Sep 2, 2017, at 11:09 PM, Pierre Habouzit <[email protected]> >>> wrote: >>> >>> On Sep 2, 2017, at 12:19 PM, Pierre Habouzit <[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 >>> >>> This seems like an interesting extension (where the actor-internal >>> serial queue is not used / bypassed). >>> >>> >>> Daniel. >>> _______________________________________________ >>> 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 >> >> _______________________________________________ > 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
