💡
Article written by AI under human supervision & guidance.
## The False Sense of Security
Consider this innocent-looking actor:
```swift
actor BankAccount {
private var balance: Double = 1000
func withdraw(_ amount: Double) async -> Bool {
// Check if we have sufficient funds
guard balance >= amount else {
return false
}
// Simulate an async operation (logging, validation, network call, etc.)
await performAsyncValidation()
// Deduct the amount
balance -= amount
return true
}
private func performAsyncValidation() async {
try? await Task.sleep(for: .milliseconds(100))
}
}
```
Looks safe, right? The actor should serialize access to `balance`. Let's test it:
```swift
let account = BankAccount()
async let withdrawal1 = account.withdraw(600)
async let withdrawal2 = account.withdraw(600)
let results = await [withdrawal1, withdrawal2]
print(results) // [true, true] — Wait, what?!
print(await account.getBalance()) // 💥 -200
```
**Both withdrawals succeeded, and we've gone negative.** This is a data race.
## Why Does This Happen? The Mailbox Model
Actors only do one thing at a time—that's true. But actors also **don't like to sit around doing nothing**. Think of an actor as having a "mailbox" of pending work. When you call an actor method, you're dropping a message into that mailbox.
Here's the key insight: **when an actor method hits an** `await`, it suspends—and the actor immediately picks up the next message from its mailbox rather than waiting idle.
Here's the sequence that leads to our bug:
1. `withdraw(600)` #1 starts, checks `balance >= 600` ✅ (balance is 1000)
2. `withdraw(600)` #1 hits `await performAsyncValidation()` and **suspends**
3. **Actor picks up next message:** `withdraw(600)` #2 starts (re-entrancy!)
4. #2 checks `balance >= 600` ✅ (balance is *still* 1000—#1 hasn't modified it yet)
5. #2 hits `await` and suspends
6. #1 resumes, deducts 600 → balance is now 400
7. #2 resumes, deducts 600 → balance is now -200 💥
The `guard` check and the mutation are not atomic across the `await` boundary. The actor only guarantees that **synchronous**code blocks don't interleave.
## Two Flavors of Re-Entrancy Problems
Re-entrancy can cause two distinct types of issues:
### Problem 1: Incorrect State (Data Corruption)
This is what we saw above—multiple operations interleave and corrupt shared state, leading to invalid results like a negative bank balance.
### Problem 2: Wasteful Duplicate Work
Even when state doesn't get corrupted, re-entrancy can cause unnecessary work. Consider a cache that fetches from a remote server:
```swift
actor DataCache {
private var cache: [UUID: Data] = [:]
func read(_ key: UUID) async -> Data? {
if let data = cache[key] {
return data
}
// Fetch from remote if not cached locally
guard let data = try? await fetchFromServer(key) else {
return nil
}
cache[key] = data
return data
}
}
```
When multiple concurrent reads request the same uncached key:
```plaintext
cache read called for DDFA2377-...
attempt to read remote cache for DDFA2377-...
cache read called for DDFA2377-... // Re-entrancy!
attempt to read remote cache for DDFA2377-... // Duplicate request!
cache read called for DDFA2377-... // Re-entrancy again!
attempt to read remote cache for DDFA2377-... // Another duplicate!
```
We made **three network requests** when one would have sufficed. The first request would have cached the result for the others—but they all started before any completed.
---
Now let's look at strategies to handle both types of problems.
## Strategy 1: Bounce Concurrent Requests
The simplest approach: if an operation is already in progress, reject new requests immediately.
```swift
actor BankAccount {
private var balance: Double = 1000
private var isWithdrawing = false
enum WithdrawError: Error {
case operationInProgress
case insufficientFunds
}
func withdraw(_ amount: Double) async throws -> Double {
// Reject if another withdrawal is in progress
guard !isWithdrawing else {
throw WithdrawError.operationInProgress
}
isWithdrawing = true
defer { isWithdrawing = false }
guard balance >= amount else {
throw WithdrawError.insufficientFunds
}
await performAsyncValidation()
balance -= amount
return balance
}
}
```
**When to use:** Idempotent operations, UI button debouncing, preventing duplicate submissions.
**Pros:** Simple, explicit, fast failure.
**Cons:** Callers must handle rejection and potentially retry.
## Strategy 2: Queue and Await Previous Operations
Instead of rejecting concurrent requests, queue them up and process them serially.
```swift
actor BankAccount {
private var balance: Double = 1000
private var pendingOperations: [CheckedContinuation