> The object can be released, making the pointer invalid. Imagine a read > that's concurrent with a store, when the property holds the only reference to > the object. > > You can actually do stores safely with an atomic exchange, but you cannot do > a load without something equivalent to a spin lock that can be held for the > duration of the retain.
Ah, yeah, right. While the read of the pointer is atomic and the retain is atomic, the combination of both is not. Sorry, forgot about this :). > If the property has ever autoreleased its result, it can be difficult for > binary compatibility reasons to make it no longer autorelease. What was the rationale then to make atomic the default? And why is everything in Foundation marked atomic, when a quick look in a disassembler reveals it's not? Shouldn't it be marked nonatomic and the fact that it still retains and autoreleases for historic reasons becomes an implementation detail then? Seems closer to what it actually does. -- 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]
