ARC weak reference zeroing in concurrent block execution

Direct answer

Under standard ARC, the promotion of a __weak reference to a strong local variable inside a block is atomic with respect to deallocation. The runtime does not expose a window in which a weak pointer is read, zeroed by another thread's dealloc, and then dereferenced as a dangling address.

Confirmed behavior vs. implementation details

Confirmed: When you assign a __weak variable to a strong local, the compiler emits an atomic weak-load-and-retain. The operation returns either a +1 retained live object or nil. If the object has already entered deallocation and the weak table entry has been cleared, you receive nil; otherwise you receive a valid object. There is no intermediate state visible to your code.

Implementation detail: The atomicity is provided by the Objective-C runtime's weak table, which synchronizes entry clearing with weak loads. The exact mechanism—historically a spinlock or compare-and-swap—is internal and subject to change. Rely on the observable contract, not the locking strategy.

When synchronization can actually fail

A race is possible only if you bypass ARC-managed promotion:

• Using __unsafe_unretained or raw C pointers instead of __weak.
• Manually manipulating the runtime weak table or using private runtime functions.
• Mixing ARC and non-ARC objects without correct bridging, causing the weak entry to be cleared while a raw pointer is still in use.

If your code uses pure __weak variables and standard strong assignment, there is no concurrency condition under which zeroing races with the strong assignment.

Practical verification

1. Create an object referenced only by a __weak variable. Dispatch many concurrent blocks that each promote the weak reference to a strong local and use it. Assert that every block receives either a valid retained object or nil, never a crash.
2. Run the test under Thread Sanitizer (-fsanitize=thread). Interpret weak-table warnings with care: the analyzer may report false positives on the runtime's internal synchronization because it is not visible to the tool.
3. Add a breakpoint or log in dealloc to confirm that promotions either complete before deallocation begins or return nil after the weak entry is cleared.

One diagnostic detail

If you are observing a crash or a sanitizer report on a weak reference, confirm whether the variable is declared __weak or __unsafe_unretained. That single detail determines whether the issue is a runtime defect or a manual memory-management mistake.