Your 🧠 on Swift Concurrency

Making a basic network call
let (data, response) = try await URLSession.shared.data(from: someURL)

!
Hi, I'm Donny
donnywals.com 2023

Your
!
on Swift Concurrency
donnywals.com 2023

So we should always make sure to
await on a background thread,
right?

You said the await means that we
suspend execution. So aren't we
blocking our thread?

An await does not block your
current thread. It allows
suspension of the current
task.

While we're suspended,
other tasks can make
progress

At this point in a workshop,
there's almost always one
person that I see thinking
really hard.

Threading in a non-concurreny
context
func someVerySlowOperation() {
// this takes a while...
}
DispatchQueue.main.async {
someVerySlowOperation()
}

Threading in a non-concurreny
context
func someVerySlowOperation() {
}
DispatchQueue.global().async {
someVerySlowOperation()
}

The same code but with Swift
Concurrency
func someVerySlowOperation() async {
}
await MainActor.run {
await someVerySlowOperation()
}

So, how can we know?
Should we use Task or
Task.detached to be sure?

What does this really mean?
func someVerySlowOperation() async {
}
Task.detached {
await someVerySlowOperation()
}

This doesn't change
anything;
someVerySlowOperation still
runs in the same way.

The system does not care
where you call something
from

Functions run on:
1. Main Actor (Main thread)
2. Global executor (Every thread except main)

So how do we decide or
determine where a certain
function will run?

This function runs on the global
executor
class MyViewModel: ObservableObject {
func performSomeWork() async {
// this will always run on the Global executor
}
}

A practical example...
struct ContentView: View {
@StateObject var vm = MyViewModel()
var body: some View {
Button {
Task {
await performSomeWork()
}
} label: {
Text("Test")
}
}
}

Changing the execution context
@MainActor func performSomeWork() async {
// this will always run on the Main actor / thread
}
}

This is much harder to reason about
@MainActor
func performSomeWork() async {
// this will always run on the Main actor / thread
}
}

So did that make the await blocking?

Opting out of main actor isolation
@MainActor
nonisolated func performSomeWork() async {
// this will _not_ run on the Main actor / thread
}
}

Async functions will run on
the global executor unless
they were specifically
instructed to not do that

So here's an even trickier one for
you...
struct ContentView: View {
@StateObject var myViewModel = MyViewModel()
var body: some View {
Button("Test") {
Task {
await someExpensiveOperation()
}
}
}
private func someExpensiveOperation() async {
// where does this function run?
}
}

SwiftUI views get an implicit
main actor annotation when
they hold an observable
object...

So... what can we take away from
this?
• Key rule: Functions run on the global executor unless otherwise
speciﬁed.
• Mark method or enclosing objext as @MainActor to enforce main
actor
• Use nonisolated to break free speciﬁc methods
• SwiftUI views with observable objects are implicitly @MainActor

So what about Tasks?
What good are they if they don't
affect where stuff runs?...

Creating an unstructured task
Task {
// I'm an unstructured task
}

Creating a detached task
Task.detached {
// I'm a detached task
}

We can make our task produce a
result too:
let task = Task {
return await someOperation()
}
let value = await task.value

What happens when we create a
task...
• Unstructured tasks inherit parts of their creation context
• Unstructured tasks are not child tasks of their creation context
• Detached tasks inherit noting
• Both tasks are their own islands of concurrency

So when do we use each?
• As little as possible
• Generally speaking we should use unstructured tasks
• Detached should only be used as a last resort

What about structured
concurrency?

It's one of the few actually
recently "invented"
paradigms in programming

It's one of the few actually
recently "invented"
paradigms in programming
Even though it's based on something from the 60's...

Structured concurrency
relates to tasks and their
children

Fetching multiple things
concurrently
func fetchUserInformation() async throws -> Profile {
let user = try await userProvider.currentUser()
async let favorites = userInfoProvider.favorites(for: user)
async let friends = userInfoProvider.friends(for: user)
async let posts = userInfoProvider.posts(for: user)
return try await Profile(for: user, favorites: favorites,
friends: friends, posts: posts)
}

Structured concurrency as a graph

Because this is structured
concurrency, the parent task
cannot complete before its
children complete.

Let's see what happens
when we add an
unstructured task

Let's talk about actors real
quick

Actors synchronize access to their
(mutable) state
actor DateFormatters {
private var formatters: [String: DateFormatter] = [:]
func formatter(using dateFormat: String) -> DateFormatter {
if let formatter = formatters[dateFormat] {
return formatter
}
let newFormatter = DateFormatter()
newFormatter.dateFormat = dateFormat
formatters[dateFormat] = newFormatter
return newFormatter
}
}

Concurrent calls to
formatter(using:) will be
serialized

So an actor is like a serial
queue then?

A suspended actor is not
locked

actor DataProcessor {
var items = Set<Item>()
func processItem(_ item: Item) async {
guard items.count < 10 && !items.contains(item) else {
return
}
let result = await upload(item)
// items might now contain the item
// items might now have a count > 10
items.insert(item)
}
}

In Summary
• Building a mental model around what runs where isn't trivial
• Await is not a blocking operation
• Functions run on the global executor unless instructed otherwise
• Create tasks only when needed
• Strucured concurrency describes the relationship between
parent and child tasks
• Actors are not like serials queues

Your 🧠 on Swift Concurrency

More Related Content

Similar to Your 🧠 on Swift Concurrency

More from Donny Wals

Recently uploaded

Your 🧠 on Swift Concurrency