On Jan 29, 2015, at 17:03 , Graham Cox <graham....@bigpond.com> wrote: > > Regarding 'nonatomic', in previous times, I've had a different warning when I > used @synthesize with an assigned ivar and the property was not 'nonatomic'. > Maybe that's changed but as a result of it I got conditioned to always > including nonatomic for my properties when I wanted to back them with an ivar.
There used to be errors when the ivar’s actual declaration didn’t match the implicit declaration if it would be synthesized. But this has been fixed for quite a while. > From what you're saying, that's not necessary (any more?) if so, it makes a > lot of my property declarations wrong, or at least verbose. Semantically, “nonatomic” is a better choice, because it emphasizes that thread safety usually comes from something other than atomicity. Unfortunately, the default is “atomic” for historical reasons — a poor decision, in hindsight. > Why even have atomic/nonatomic if there's no difference, and if you're > writing your own setters (a different but related issue), how can you make > them atomic anyway? a. There’s a difference if the property value is (say) a struct. b. There’s no API contract that there’s no difference. It just happens to be true, which means you don’t have to feel anxious about performance with (most) atomic properties. In theory, there could be a new supported hardware architecture in the future where it matters. (IIRC, it wasn't true for PPC architectures, but the locking mechanism was pretty cheap.) c. If you write your own setter, there’s no way to hook into the atomicity mechanism that @synthesize uses. For an atomic non-synthesized property, you’d have to provide both a getter and a setter, to get it to actually be atomic. And you’d have to do the synchronization yourself, of course. d. The compiler can’t tell whether you made your (explicit) accessors atomic, and it doesn’t try. Again in hindsight, the implementation details seem fairly screwed up, all the way down the line. <shrug> _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
