The typical use-case for atomic
properties is when dealing with a primitive data type across multiple threads. For example, let's say you have some background thread doing some processing and you have some BOOL
state property, e.g. isProcessComplete
and your main thread wants to check to see if the background process is complete:
if (self.isProcessComplete) {
// Do something
}
In this case, declaring this property as atomic
allows us to use/update this property across multiple threads without any more complicated synchronization mechanism because:
- we're dealing with a scalar, primitive data type, e.g.
BOOL
;
- we declared it to be
atomic
; and
- we're using the accessor method (e.g.
self.
) rather than accessing the ivar directly.
When dealing with objects or other more complicated situations, atomic
generally is insufficient. As you point out, in practice, atomic
, alone, is rarely sufficient to achieve thread safety, which is why we don't use it very often. But for simple, stand-alone, primitive data types, atomic
can be an easy way to ensure safe access across multiple threads.