ARC Weak Reference Zeroing Limits in Multithreaded Contexts

Question

Automatic Reference Counting (ARC) in Objective-C manages object lifecycles by automatically zeroing out __weak references when the referenced object is deallocated. This behavior prevents dangling pointers by ensuring the pointer becomes nil before it is accessed.

In complex multithreaded environments, there is a potential race condition between the runtime's process of zeroing the weak pointer and a concurrent read operation on another thread. While the runtime handles the synchronization of the reference count, the exact atomicity of the zeroing process relative to pointer access is a critical design consideration for thread safety.

Does the Objective-C runtime guarantee that a __weak reference access is atomic relative to the deallocation and zeroing process?
  Under what conditions might a thread read a non-nil value for a weak reference while the object is simultaneously being reclaimed?

Tasadduq Burney · Answer

Does the runtime guarantee atomic zeroing of __weak references?
Yes. The Objective‑C runtime implements every ARC read of a __weak variable through the function objc_loadWeakRetained. This function atomically loads the pointer and attempts a retain; if the retain fails because the object is already beginning deallocation, it returns nil. Because the load and the conditional retain are performed as a single atomic operation, a thread can never obtain a dangling pointer – the result is either a valid retained object or nil.
When could a thread observe a non‑nil weak reference while the object is being reclaimed?
Only when the weak pointer is accessed outside ARC’s safety net. Typical ways include:

Using __unsafe_unretained or casting the variable to id* and dereferencing it directly.
Running on a platform that predates zeroing weak references (iOS < 5, OS X < 10.7).
Defining a custom accessor macro that reads the raw storage (e.g., *((id *)&weakVar)).

Under normal ARC usage – assigning the weak variable to a strong temporary, passing it as a method argument, or using it in an expression – the guarantee holds and no non‑nil value can be seen while the object is being freed.
Practical verification steps

Declare a __weak property or variable.
In one thread, repeatedly read it via ARC (e.g., __strong MyClass *tmp = weakRef;).
In another thread, release the last strong reference to let the object deallocate.
Check that each read yields either nil or a live object that does not crash when used.
Run under Thread Sanitizer or with os_signpost to confirm no race warnings.

If you observe a crash, verify that the weak reference is never accessed through __unsafe_unretained or a raw pointer cast.

ARC Weak Reference Zeroing Limits in Multithreaded Contexts

1 answer

Does the runtime guarantee atomic zeroing of __weak references?

When could a thread observe a non‑nil weak reference while the object is being reclaimed?

Practical verification steps

Your perspective belongs here.

0 question comments