Managing State Consistency with Swift Actors and Reentrancy

The Problem: Data Races vs. State Inconsistency

In concurrent Swift applications, the primary goal is avoiding data races—where two threads access the same memory simultaneously and at least one access is a write. While Swift Actors solve the data race problem by ensuring mutually exclusive access to their internal state, they introduce a different challenge: Actor Reentrancy.

An actor is not a traditional lock. When an actor reaches an await keyword, it suspends its current execution to allow other tasks to run. This prevents deadlocks but means the actor's state may change while a function is suspended. If your logic assumes the state remains identical before and after an await, your application will suffer from logical state inconsistency.

The Smallest Suitable Design: The Isolated State Pattern

To implement a thread-safe manager, use an actor for state isolation and the Sendable protocol for data crossing boundaries. Sendable is a marker protocol indicating that a value can be safely shared across concurrency domains (e.g., value types like Structs or final classes with immutable properties).

Example: A Concurrent Image Cache

// Ensure the data being passed is Sendable to prevent data races
struct CacheEntry: Sendable {
    let data: Data
    let timestamp: Date
}

actor ImageCache {
    private var cache: [URL: CacheEntry] = [:]

    func getImage(for url: URL) async throws -> Data {
        // Check if we already have the image
        if let entry = cache[url] {
            return entry.data
        }

        // SUSPENSION POINT: The actor is now free to process other requests
        let data = try await downloadImage(from: url)

        // CRITICAL: State may have changed during the await
        // Another task might have already cached this URL
        cache[url] = CacheEntry(data: data, timestamp: Date())
        return data
    }

    private func downloadImage(from url: URL) async throws -> Data {
        let (data, _) = try await URLSession.shared.data(from: url)
        return data
    }
}

Trust and Data Boundaries

Data boundaries in Swift concurrency are defined by the Sendable check. When passing data into an actor, the compiler verifies that the type cannot be mutated from the outside once passed in.

• Internal State: Private to the actor; accessible only via async calls.
• Boundary Data: Must conform to Sendable. If you must pass a non-Sendable class, you must ensure it is deeply immutable or managed via a lock, though this bypasses the benefits of the actor model.
• Main Thread Boundary: Use @MainActor for any code that touches the UI. This is a global actor that ensures execution on the main dispatch queue.

Operational Checks and Verification

To verify that your actor boundaries are secure, you must enable strict concurrency checking. This moves many runtime risks to compile-time errors.

Configuration: In Xcode, go to Build Settings > Swift Compiler - Code Generation > Strict Concurrency Checking and set it to Complete. Alternatively, add the following flag to your build command:

swift build -Xswiftc -strict-concurrency=complete

Verification Test: Attempt to mutate an actor's property from a Task without using await. The compiler should throw an error: Actor-isolated property '...' can only be referenced from within the actor.

Failure Modes and Reentrancy Risks

The most common failure mode is the Interleaving Gap. This occurs when a developer performs a check, awaits a result, and then performs an action based on the initial check without re-verifying the state.

Scenario	Risk	Mitigation
Check-then-Act	State changes during await, leading to duplicate work or invalid state.	Re-verify conditions immediately after the await call.
MainActor Overload	Heavy computation on @MainActor freezes the UI.	Move heavy logic to a separate actor or nonisolated function.
Circular Awaits	Actor A awaits Actor B, which awaits Actor A.	While not a traditional deadlock, it creates a dependency chain that can degrade performance.

Conditions for Design Change

The Actor model is ideal for managing shared state, but you should pivot to other designs if:

• High-Frequency Synchronous Access: If you need to access state thousands of times per second without async overhead, a DispatchQueue or OSAllocatedUnfairLock may be more performant.
• Complex Transactional Logic: If you need to lock multiple resources simultaneously for a single atomic operation, actors are insufficient because they only isolate their own state. In these cases, a centralized coordinator or a traditional mutex may be required.