> The lock is necessary because atomic properties promise that concurrent reads > and writes will yield consistent values without crashing.
Meaning you need to atomically read and write a pointer. Which all modern architectures do. Or what am I missing here? If you have void *foo and set it in thread A while reading it in thread B, nothing bad will happen on all modern architectures: The write can only be completed atomically, it's impossible to only write half the bytes. So what's the purpose, other than for machines where this is not the case (I cannot think of one where it's not)? > That is the primary semantic guarantee of atomic properties. If you believe > that that guarantee is pointless, you are arguing for the use of nonatomic > properties. I'd be arguing for nonatomic if it does not skip the retain and release, but unfortunately, it does. > Whether or not a property getter autoreleases its return value is unrelated > to atomic properties except inasmuch as an atomic property getter must retain > its current value in order to satisfy its semantic guarantee, and that retain > has to be balanced somehow. When an atomic property can satisfy its semantic > guarantee without retaining — for example, if it has a guarantee that the > value is retained elsewhere, e.g. as an __unsafe_unretained property does — > then the getter does not need to autorelease the result. Has that always been the case? Looking into Foundation, it seems that objc_getProperty isn't used much, but instead the you have the [[iVar retain] autorelease] pattern all over the place. If that were always the case, why the retain and autorelease there then instead of just return? -- Jonathan _______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
