Re: How did gcc handle synthesized atomic vs custom nonatomic setter/getter?
Re: How did gcc handle synthesized atomic vs custom nonatomic setter/getter?
- Subject: Re: How did gcc handle synthesized atomic vs custom nonatomic setter/getter?
- From: Kyle Sluder <email@hidden>
- Date: Sun, 10 Oct 2010 11:37:53 -0700
On Oct 10, 2010, at 11:10 AM, Bill Bumgarner <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden