Sometimes we have a simple readOnly Property whose value may change
@property (readonly) NSFetchedResultsController * FetchController;
@property (readonly) NSFet
It is a common misconception to consider read-only operations as atomic in nature. It isn't guaranteed. It is also a common misconception that atomicity guarantees thread safety, but that is a different subject.
The difference between atomic and nonatomic on readonly properties is that atomic
(which is the default, but not declared) guarantees that the value returned from the readonly retrieval method is integral.
That is, if it is an object, it will be retained and autoreleased. If it is a struct, an appropriate lock will have been used to ensure an integral value of the struct was returned.
Note that simply because a property is declared publicly readonly does not preclude it being re-declared as readwrite for internal use. Thus, the difference between atomic and nonatomic might be quite significant; a class might declare a readonly property as nonatomic while also documenting that all API on the class must be used from one thread only.