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

[Philippe Hausler]

I have read over the proposal and already asked a few questions ahead of the email chain and I have some follow up points that are perhaps worth consideration.

First off, I think that async/await is a great concept! From personally using a similar concept in C#, I think it can be an approachable yet powerful tool to resolve a decent number of problems with threading. It is worth stating, however, that it does NOT solve all problems with threading, or at least, not on its own.

One thing I have in mind is that Swift, of course, does exist in a vacuum. It, by nature, is being used for writing iOS, watchOS and macOS applications to be shipped on those platforms. On those platforms, libdispatch is often used for things like completion handlers and similar (or indirectly used via NSOperationQueue). Of course there are a few of those devices that only have one core or are thermally constrained under load. It is then imperative that applications (at least under the hood) utilize appropriate quality of service to ensure that certain workloads do not get scheduled as much as others. For example: if an application is synchronizing some sort of state over the network, it may be the best choice to run that work at a low quality-of-service. In this example, if a specific piece of work is then blocked by the work that is running at a low quality-of-service, it needs to temporarily override that low quality-of-service to match the blocked work. I think that any concurrency model we consider should be able to work constructively with a situation like this, and take QoS into account.

For sake of argument, though: let's presume that completion handlers are always going to be appropriately scheduled for their quality-of-service. So why is the override important to think about? Well... in the cases of single core, or other cases where a ton of work in limiting the number of cores available, there can be a problem known as a priority inversion. If no override is made, the low priority work can be starved by the scheduling of a waiter. This results in a deadlock. Now you might of course think: "oh hey, that's DispatchSemaphore's responsibility, or pthread_condition_t" etc... Unfortunately semaphores or conditions do not have the appropriate information to convey this. To offer a solution to this problem, the start of the asynchronous work needs to be recorded for the threads involved to the end of that asynchronous work, then at the beginning of the waiting section an override needs to be created against those asynchronous threads and the override is ended at the point that it is done waiting.

In short, effectively just waiting on completion handler will cause severe performance problems - to resolve this it seems like we absolutely need to have more entry points to do the correct promotions of QoS. 

What do you think is the best way of approaching a resolution for this potential pitfall?

> On Aug 17, 2017, at 3:24 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi all,
> 
> As Ted mentioned in his email, it is great to finally kick off discussions for what concurrency should look like in Swift.  This will surely be an epic multi-year journey, but it is more important to find the right design than to get there fast.
> 
> I’ve been advocating for a specific model involving async/await and actors for many years now.  Handwaving only goes so far, so some folks asked me to write them down to make the discussion more helpful and concrete.  While I hope these ideas help push the discussion on concurrency forward, this isn’t in any way meant to cut off other directions: in fact I hope it helps give proponents of other designs a model to follow: a discussion giving extensive rationale, combined with the long term story arc to show that the features fit together.
> 
> Anyway, here is the document, I hope it is useful, and I’d love to hear comments and suggestions for improvement:
> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
> 
> -Chris
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution