[swift-evolution] [Concurrency] async/await + actors
Pierre Habouzit
phabouzit at apple.com
Tue Sep 5 11:47:59 CDT 2017
> On Sep 5, 2017, at 9:29 AM, Wallacy via swift-evolution <swift-evolution at swift.org> 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 <phabouzit at apple.com <mailto:phabouzit at apple.com>> escreveu:
>> On Sep 4, 2017, at 7:27 AM, Wallacy via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >> On Sep 2, 2017, at 11:09 PM, Pierre Habouzit <phabouzit at apple.com <mailto:phabouzit at apple.com>> wrote:
>> >>> On Sep 2, 2017, at 12:19 PM, Pierre Habouzit <pierre at habouzit.net <mailto:pierre at habouzit.net>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170905/90d79693/attachment.html>
More information about the swift-evolution
mailing list