[swift-evolution] [Concurrency] async/await + actors

Tue Sep 5 11:50:52 CDT 2017

Fair enough! Tranks!

Em ter, 5 de set de 2017 às 13:48, Pierre Habouzit <phabouzit at apple.com>
escreveu:

> 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>
> escreveu:
>
>> On Sep 4, 2017, at 7:27 AM, Wallacy via swift-evolution <
>> 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> 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> wrote:
>>> >> On Sep 2, 2017, at 11:09 PM, Pierre Habouzit <phabouzit at apple.com>
>>> wrote:
>>> >>> On Sep 2, 2017, at 12:19 PM, Pierre Habouzit <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
>>>
>>> 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
>>> 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
>>
>> _______________________________________________
> 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/48a84957/attachment.html>