Can actor reentrancy cause stale cached reads across await points in Swift

The Impact of Actor Reentrancy on State Consistency

Yes, actor reentrancy can cause stale cached reads across await points. Swift actors do not guarantee that isolated state remains unchanged while a task is suspended. When a task reaches an await, it yields the actor's executor, allowing other pending tasks to run on that same actor. If those interleaved tasks mutate the state, any value you read and stored in a local variable before the suspension will be logically stale when the original task resumes.

Logical Staleness vs. Data Races

It is important to distinguish between memory safety and logical consistency. Swift actors prevent data races (simultaneous unsynchronized access to memory), but they do not prevent race conditions (logical errors caused by the order of execution). The compiler ensures that accessing the state is safe, but it cannot ensure that the value of that state hasn't changed during a suspension point.

Safe Patterns for State Preservation

To avoid logic errors caused by reentrancy, use the following strategies based on your consistency requirements:

• Re-verify after resume: If the logic depends on the current state, re-read the actor property immediately after the await point rather than relying on a pre-await local constant.
• Explicit Snapshotting: If you specifically need the state as it existed at the start of the operation, capture it into a local value type (struct). Be aware that this is a snapshot of the past and may not reflect the current reality of the actor.
• Atomic State Transitions: Structure your code to perform all mutations after the await point. Avoid the "read-await-write" pattern where the write is based on the pre-await read.

MainActor vs. Custom Actors

There is no difference in reentrancy behavior between MainActor and custom actors. While MainActor uses the main thread as its executor, it follows the same reentrancy model: any await allows other tasks to be scheduled on the main thread, potentially mutating MainActor-isolated state before the suspended task resumes.

Verification Example

You can verify this behavior with a simple test case. If an actor method reads a counter, calls await Task.yield(), and then checks the counter again, you will find that other tasks can increment that counter during the yield, rendering the first read stale.

actor Counter {
    var value = 0
    func increment() { value += 1 }

    func checkStaleness() async {
        let initial = value
        await Task.yield() // Suspension point
        if value != initial {
            print("State became stale!")
        }
    }
}