[swift-evolution] [Concurrency] async/await + actors
Marc Schlichte
marc.schlichte at googlemail.com
Sat Aug 26 09:52:53 CDT 2017
> Am 26.08.2017 um 02:03 schrieb Adam Kemp via swift-evolution <swift-evolution at swift.org>:
>
> I’m not sure I understand. What is the connection between references and deadlocks?
This is what I had in mind:
To have a deadlock from async actor methods, you would need some mutual invocations of them - i.e a cycle in the call graph.
If your code is (strong) retain cycle free and you make invocations only on actors of which you have strong references, you will also have no cyclic call graph, hence no deadlocks.
Now, unfortunately - and contrary to my claim - deadlocks still can happen:
if you `await` in your async actor method on some state which can only be set via another actor method in your actor, a deadlock occurs:
Example:
```
actor class A {
var continuation: (() -> Void)?
actor func m1() async {
await suspendAsync { cont in
continuation = cont
}
}
actor func m2() {
continuation?()
}
}
```
If someone calls `a.m1()`, and someone else `a.m2()`, `a.m1()` still does not complete as `a.m2()` is not allowed to run while `a.m1()` is not finished.
Marking `m2` as an `interleaved actor func` would remedy that situation as it could then run when the next work item is picked from the serial gdc queue - which can happen while we `await` on the `suspendAsync` in the example above.
Cheers
Marc
>
>> On Aug 25, 2017, at 1:07 PM, Marc Schlichte <marc.schlichte at googlemail.com <mailto:marc.schlichte at googlemail.com>> wrote:
>>
>>
>>> Am 25.08.2017 um 19:08 schrieb Adam Kemp via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>>
>>> I understand what you’re saying, but I just think trying to make synchronous, blocking actor methods goes against the fundamental ideal of the actor model, and it’s a recipe for disaster. When actors communicate with each other that communication needs to be asynchronous or you will get deadlocks. It’s not just going to be a corner case. It’s going to be a very frequent occurrence.
>>>
>>> One of the general rules of multithreaded programming is “don’t call unknown code while holding a lock”. Blocking a queue is effectively the same as holding a lock, and calling another actor is calling unknown code. So if the model works that way then the language itself will be encouraging people to call unknown code while holding locks. That is not going to go well.
>>>
>>
>> I would claim - without having a prove though - that as long as you don’t invoke async actor methods on weak or unowned actor references and the code is retain cycle free, no deadlocks will happen.
>>
>> Cheers
>> Marc
>>
>
> _______________________________________________
> 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/20170826/e28eb3f2/attachment.html>
More information about the swift-evolution
mailing list