Actor concurrent/parallel execution

pyretttt · July 4, 2022, 10:28am

Hello guys, could you tell me guys. Do swift actors support parallel execution overall?
After some source code research and few articles read - I make assumption that all custom actor direct they calls to global executor, which manages global thread pool. Exception is MainActor which is whole standalone thing.
I know that blocking operations inside task is not allowed, it may broke dispatching of executor, but I don't know any other ideas how to test it.

So my example is:

actor SomeActor {
    let name: String
    
    init(_ name: String) { self.name = name }
    
    func run() {
        print("Start run: (name)")
        sleep(5)
        print("End run: (name)")
    }
}
let act1 = SomeActor("A")
let act2 = SomeActor("B")
Task.detached {
    await act1.run()
}
Task.detached {
    await act2.run()
}

Output is: 
Start run: A
End run: A
Start run: B
End run: B

Why do actors run serially, taking into account that they are invoked from detached task?
Do actors support parallelism, or they are concurrent only?
Will appreciate any ideas and assumptions)

ole · July 4, 2022, 10:56am

How are you testing this? What OS/environment?

If I change your code as follows to make it compile and to await the two tasks before exiting, and then run it on the command line (swift actors.swift), the two tasks do run concurrently as you would expect.

+import Foundation
+
 actor SomeActor {
     let name: String
     
     init(_ name: String) { self.name = name }
     
     func run() {
-        print("Start run: (name)")
+        print("Start run: \(name)")
         sleep(5)
-        print("End run: (name)")
+        print("End run: \(name)")
     }
 }
 let act1 = SomeActor("A")
 let act2 = SomeActor("B")
-Task.detached {
+let t1 = Task.detached {
     await act1.run()
 }
-Task.detached {
+let t2 = Task.detached {
     await act2.run()
 }
+
+await t1.value
+await t2.value

Output:

$ swift actors.swift
Start run: A
Start run: B
End run: B
End run: A

Environment: macOS 12.4, Swift 5.7 (Xcode 14.0b2)

pyretttt · July 4, 2022, 11:10am

Tried your changes still serially, my config are:
macOS 12.4
Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
Target: x86_64-apple-macosx12.0
Xcode Version 13.3 (13E113)

Avi · July 4, 2022, 11:13am

How are you determining this? The order in which they complete is not deterministic.

pyretttt · July 4, 2022, 11:17am

Output is showing the actual order, btw question is not about order. It is about concurrency mechanism actor & executors use

ole · July 4, 2022, 11:21am

I don't get this. My code doesn't even compile for me in Xcode 13.3 (or 13.4.1), presumably because SE-0343 Concurrency in Top-level Code was only implemented in Swift 5.7.

$ sudo xcode-select --switch /Applications/Xcode-13.3.app/Contents/Developer/

$ swift --version
swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
Target: arm64-apple-macosx12.0

$ swift actors.swift
actors.swift:23:7: error: 'async' property access in a function that does not support concurrency
await t1.value
      ^
actors.swift:24:7: error: 'async' property access in a function that does not support concurrency
await t2.value
      ^

pyretttt · July 4, 2022, 11:29am

I did it inside another Task

Task {
     await t1
     await t2
}

I think it doesn't make any sense. Probably there are changes between versions of swift that bring something new.
Even these proposal could change it's implementation:

github.com

apple/swift-evolution/blob/main/proposals/0338-clarify-execution-non-actor-async.md

# Clarify the Execution of Non-Actor-Isolated Async Functions

* Proposal: [SE-0338](0338-clarify-execution-non-actor-async.md)
* Author: [John McCall](https://github.com/rjmccall)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 5.7)** ([Decision notes](https://forums.swift.org/t/accepted-se-0338-clarify-the-execution-of-non-actor-isolated-async-functions/54929))

## Introduction

[SE-0306](https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md), which introduced actors to Swift, states that `async` functions may be actor-isolated, meaning that they formally run on some actor's executor.  Nothing in either SE-0306 or [SE-0296](https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md) (`async`/`await`) ever specifies where asynchronous functions that *aren't* actor-isolated run.  This proposal clarifies that they do not run on any actor's executor, and it tightens up the rules for [sendability checking](https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md) to avoid a potential data race.

## Motivation

It is sometimes important that programmers be able to understand which executor is formally responsible for running a particular piece of code.  A function that does a large amount of computation on an actor's executor will prevent other tasks from making progress on that actor.  The proper isolation of a value may also depend on only accessing it from a particular executor (see note below).  Furthermore, in some situations the current executor has other semantic impacts, such as being "inherited" by tasks created with the `Task` initializer.  Therefore, Swift needs to provide an intuitive and comprehensible rule for which executors are responsible for running which code.

> Note: Swift will enforce the correct isolation of data by default with `Sendable` checking.  However, this will not be fully enabled until code adopts a future language mode (probably Swift 6).  Even under that mode, it will be possible to opt out using `@unsafe Sendable`, making safety the programmer's responsibility.  And even if neither of those caveats were true, it would still be important for programmers to be able to understand the execution rules in order to understand how best to fix an isolation error.

In the current implementation of Swift, `async` functions that aren't actor-isolated never intentionally change the current executor.  That is, whenever execution enters such an `async` function, it will continue on whatever the current executor is, with no specific preference for any particular executor.

To be slightly more precise, we can identify three principle ways that execution can enter an `async` function:

This file has been truncated. show original

ole · July 4, 2022, 11:37am

But if you do just that, the tasks won't even run to completion because the program will exit before the tasks finish, won't they?

With just this single change, the output is this for me (edit: macOS 12.4, Xcode 13.3 (Swift 5.6)):

$ swift actors.swift
Start run: B
Start run: A
# program exits here
$ (new prompt)

You'd need to add something like RunLoop.current.run() to the main program (at the top level) to keep the program running. And then it does the right thing again (the two actors run concurrently).

pyretttt · July 4, 2022, 11:42am

ole:

pyretttt:
I did it inside another Task
Task {
     await t1
     await t2
}
But if you do just that, the tasks won't even run to completion because the program will exit before the tasks finish, won't they?

With just this single change, the output is this for me:
$ swift actors.swift
Start run: B
Start run: A
# program exits here
$ (new prompt)
You'd need to add something like RunLoop.current.run() to the main program (at the top level) to keep the program running. And then it does the right thing again (the two actors run concurrently).

Is it 5.6 swift?
Even though it exits before finish, second tasks start before first one is ended

I'm testing it inside test project, inside appDelegate call.
So it's okay

ole · July 4, 2022, 11:54am

Are you testing this in the iOS simulator?

pyretttt · July 4, 2022, 12:16pm

Yup, have just tried real device and got:
Start run: B
Start run: A
End run: B
End run: A

What can be the reason of difference between sim and device? My iOS version 15.5

pyretttt · July 4, 2022, 12:17pm

Just the same code in simulator runs serially

ole · July 4, 2022, 12:23pm

See, this is why it's important that you tell us your exact testing environment. We've been talking past each other.

Apparently this info from @rokhinip is still true:

The simulator needs to run on older OS-es which don't have the new cooperative thread pool with kernel support. As such, we have to make locally optimal decisions in libdispatch on how many threads to bring up in libdispatch

And:

If you had kicked off tasks with different QoS-es, you'd see that we will bring up at least a thread per QoS class but we don't have intelligent load balancing

So the simulator only uses one thread per task priority. Since your sleep call blocks the thread, nothing else can run on the cooperative thread pool in the meantime.

pyretttt · July 4, 2022, 12:45pm

Thanks man, btw I recently noticed that on simulator Task.detached runs on: com.apple.root.default-qos.cooperative (serial)
And on device it's running on:
com.apple.root.default-qos.cooperative (concurrent)

Really appreciate your help)

Dmitriy_Ignatyev · August 25, 2022, 2:03am

Actors are concurrent only, and only one task can be executed on actor at the same time. There is no parallelism primitives in Swift Concurrency, still in Swift 5.7.

Jon_Shier · August 25, 2022, 3:20am

You mean no explicit primitives, like DispatchQueue.concurrentPerform, right? Because TaskGroups and async let are usually parallel, and independent Tasks are parallel if they don't touch the same resources.

Dmitriy_Ignatyev · August 25, 2022, 3:26am

Yes, exactly. Tanks for clarification.

I want additionally to notice that they can be parallel, but it is not guaranteed. Example:
(the implementation of concurrentMap() can be found here)

Task {
  let elementsArray = Array(1...1000)
  let maped = await elementsArray.concurrentMap { number in
    print("concurrentMap start \(number) ")
    defer { print("concurrentMap end \(number) ") }
    return (1...number).map { String(describing: $0) }
  }
}

Most often I see at first sequential prints:
concurrentMap start 1
concurrentMap end 1
concurrentMap start 2
concurrentMap end 2
concurrentMap start 3
concurrentMap end 3
concurrentMap start 4
concurrentMap end 4
...

Later I see lots of task first created:
AsyncMap start 994
AsyncMap start 995
AsyncMap start 996
...

and then finished
AsyncMap end 994
AsyncMap end 995
AsyncMap end 996
....

The order of prints changes on every execution, which is expected.

oxygen · November 3, 2022, 6:10pm

After experimenting with actors I found that while the actor is doing something everything stays on the same thread even if using withTaskGroup (each task would stay on the same thread). I’m not sure if, when or why an actor might switch threads (possibly if using async await and the actor has been idle during an await?). I don’t think this is guaranteed by any kind of spec, it just appears to be so and it makes total sense.

On the other hand using classes allows withTaskGroup to use multiple threads and each await is likely to wake up on a different thread just like the docs say.

For the simple case of only using async/await for parallelism, all blocks of code inside an actor which run without encountering any awaits would be synchronous to that actor’s thread so it will never run in parallel with other code in the actor because that’s how threads work.

However, once an await is introduced in the call stack, even if it doesn’t happen experimentally all the time (like some of you tried), code would run “in parallel” to other code in the actor. I’m using quotes because it is not true parallelism (not on a different thread) but logic parallelism, in the sense that once the await is encoutered other awaiting code elsewhere in the actor will be allowed to continue if it is ready to do so which can lead to bugs in some scenarions, so queues are wanted (or sometimes you can get away with a spinlock around using a while(){Task.sleep}, and sometimes with a simple FILO array for scheduling stuff).

I’ve discovered that in both V8 JS and Swift running the CPU at 100% even on the iPad/iPhone (even if using a separate tool like a burn-in test) causes many parallelism bugs to reveal themselves, for both multithreading (async/await in classes which uses multiple threads) and, separately, async/await in actors (same thread, order of execution bugs)

When using classes, unless they’re part of the @MainActor, it is very easy to run into multithreading issues when using async/await when modifying the same variables that other code is accessing or modifying.

Note: there are no actors in NodeJS and awaits always wake up on the same thread, while threads shared memory is handled by the programmer explicitly between threads (worker_threads).