ARC weak reference zeroing timing under concurrency

Concurrency and Weak Pointer Zeroing

Weak pointer zeroing in Objective-C ARC is not guaranteed to be atomic with respect to concurrent reads on other threads. While the runtime ensures that a weak reference will eventually be set to nil when the referent is deallocated, there is no built-in synchronization primitive that forces this change to be immediately visible to all threads.

The Synchronization Gap

ARC provides no "happens-before" guarantee between the completion of an object's deallocation on Thread A and the reading of a weak reference on Thread B. Because the zeroing process is handled by the runtime's side-table mechanism, a concurrent read may return a non-nil pointer to an object that is currently in the process of being destroyed or has already been freed, leading to a race condition.

Confirmed Runtime Behavior

• Zeroing Timing: The pointer is zeroed after the referent's retain count reaches zero and the deallocation sequence begins.
• Visibility: Without explicit synchronization (e.g., @synchronized, dispatch_semaphore_t, or os_unfair_lock), a reader thread may observe a stale, non-nil value.
• Safety: The only safe way to use a weak reference across threads is to strongly capture it locally.

Safe Access Pattern

To prevent use-after-free crashes during concurrent deallocation, always convert the weak reference to a strong reference before use:

// Thread-safe access pattern
id strongObject = self.weakReference;
if (strongObject) {
    // The object is guaranteed to stay alive for the duration of this scope
    [strongObject performAction];
}

Weak vs. Unowned (unsafe_unretained)

In Objective-C, unsafe_unretained is the closest equivalent to Swift's unowned. It is only safe when the reference is guaranteed to have a shorter lifetime than the referent (e.g., a parent-child relationship where the child cannot outlive the parent). Unlike weak, unsafe_unretained never zeroes out; if the referent is deallocated, the pointer becomes dangling, and any access will result in a crash or memory corruption.

Verification

To detect these races in a development environment, compile the project with ThreadSanitizer (TSan) enabled in the Xcode Scheme. TSan can identify illegal access patterns where a weak reference is read concurrently with a deallocation event.

Note: To provide a more specific recommendation, please clarify if you are using a custom side-table implementation or standard ARC.