E.g. in NSView.h all properties are implicitly defined as atomic while clearly having manually implemented accessors (easily seen while debugging). The assembly code does not show anything that would even approximately looks as an attempt for synchronization.
Moreover, when defining custom accessors for an atomic property clang does no issue any warnings anymore.
Was the language changed to no-op atomic / nonatomic?
A lot of data types are inherently atomic simply because of the CPU architecture. For example, integers and pointers. A simple assignment is already atomic.
Have you looked at the assembly for something more complex like -setFrame:? And, in general, what version of the frameworks are you looking at?
With respect to the compiler, it did not generally warn about implementing custom accessors for atomic properties. It only warned about implementing only one of the accessors for an atomic read/write property and not the other accessor. Are you sure that it's no longer doing that? Could it be your build settings? Again, what version of Xcode or clang?
I understand that due to Intel's architecture assignment of word-sized variables is atomic. But many accessors are far more complex than that. E.g. (AppKit as of 10.14) -setFrame:, -setFrameOrigin and -setFrameSize (in particular that one) are far from being simple.
> With respect to the compiler, it did not generally warn about implementing custom accessors for atomic properties.
Looks like I have recalled the behavior incorrectly. I was under impression that in the past you could not have a sythesized atomic property with a custom accessor.
Properties seem to be atomic with respect to the value (no half old value / half new value). But with respect to the instance they are not atomic.
This "atomic" doesn't have anything to do with the low-level processor concept. If you use atomic with a synthesized property, then you get something relatively thread-safe. By "relatively thread-safe" I mean "don't push your luck". If you use atomic with a getter/setter, then it doesn't mean anything. If your property is declared as atomic, the assumption is that your getter and setter will implement the atomicity.
Of course, none of that matters with a user interface object like NSView. Those are probably just "assumed" to be atomic because you shouldn't ever use them on anything other than the main thread.
IIRC atomicity was all about low level processor concept because ARM (PowerPC too?) could end up with only "half" value being set in one thread when modification happened in another thread. Extra instructions were needed for synchronization but they were redundant given that early iOS (iPhone OS) apps were single threaded.
Yes. My point was that Apple reused that well-defined term for something else. In certain cases, you can have "atomic" behaviour of properties, but in other cases, they won't be atomic at all.
That leads me to the question: what AppKit developers tried to communicate by declaring properties as atomic..
