On Oct 10, 2010, at 11:10 AM, Bill Bumgarner <b...@mac.com> wrote: > Note that 'atomic' has nothing to do with thread safety. In almost all > cases, declaring the @property as 'nonatomic' is the right answer (in that > your thread safety -- if needed -- is at a higher level of then individual > properties).
This is why I don't understand the rationale behind making atomic the default. In the only cases where it matters, you already need to be concerned about the atomicity and integrity of your operations at a higher level. As it stands, all atomic-by-default does is slow down otherwise perfectly valid code. Properties that are accidentally atomic might still be used unsafely. Back to the reason this issue has come up: we don't have access to the lock (if any) the compiler uses in an atomic property's implementation. It would be nice if we could @synchronize on a property, generating the same locking code as an atomic property. It would make writing interdependent atomic properties nicer. (Yes, this would probably mean that the synthesized atomic implementation would be slower than current and couldn't be lockless.) Now I'm thinking about named monitors… --Kyle Sluder_______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
