Atomic Accessor Locking vs Nonatomic for a Concurrently Read Flag

Question

A shared scalar property—such as a feature flag or request counter—is read and written from multiple threads during concurrent request handling. The decision is whether to keep the default synthesized atomic attribute, which wraps each accessor in a lock, or to declare the property nonatomic and remove that per-access locking.

The constraint is that accessor-level locking only guarantees individual getter and setter calls, not read-modify-write sequences or compound invariants. Under concurrent load, contention on the accessor lock may introduce latency that never appears in single-threaded tests, while nonatomic eliminates that lock but leaves multi-step updates unsynchronized. Behavior also varies with the Apple Clang toolchain, runtime, and deployment target, and ARC memory semantics remain separate from the accessor attribute.

Does the default atomic accessor lock protect a compound invariant across multiple calls, or must the property be nonatomic with external synchronization to own that invariant? What synchronization boundary is required in each case to prevent lost updates under concurrent request load?

Tasadduq Burney · Answer

Compound Invariant ProtectionAtomic vs. Nonatomic for Read-Modify-WriteThe default atomic accessor lock does not protect a compound invariant across multiple calls. It only guarantees that each individual getter and setter operation is atomic.Atomic Accessor: Protects single reads or single writes from interleaving, but a sequence like (Read Flag $\rightarrow$ Modify $\rightarrow$ Write Flag) remains vulnerable to race conditions if another thread modifies the flag between the read and the write.Nonatomic Property: Eliminates the per-access lock, requiring the developer to implement external synchronization for any multi-step update to prevent lost updates.Required Synchronization BoundaryTo prevent lost updates when maintaining a compound invariant (e.g., incrementing a counter), you must implement a synchronization boundary that encompasses the entire read-modify-write sequence, regardless of whether the property is atomic or nonatomic.Wrap the entire read-modify-write logic within an explicit lock (e.g., a dispatch queue barrier or a mutex).Alternatively, if the underlying type supports it, use a true atomic read-modify-write primitive (e.g., atomic increment/compare-and-swap) instead of relying on the property accessor.Next Diagnostic StepTo confirm the performance impact, what is the expected concurrency level (e.g., peak requests per second) under which latency due to the accessor lock becomes a measurable bottleneck?

Atomic Accessor Locking vs Nonatomic for a Concurrently Read Flag

1 answer

Compound Invariant Protection

Atomic vs. Nonatomic for Read-Modify-Write

Required Synchronization Boundary

Next Diagnostic Step

Your perspective belongs here.

0 question comments