> On Apr 30, 2017, at 9:15 AM, Jonathan Schleifer <[email protected]> > wrote: >> 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?
I can't speak to that decision: it pre-dates me. At a guess, probably over-enthusiasm for the idea of eliminating low-level failures due to races, buoyed by the era's general optimism about the ability of future machines to hide the performance cost. Atomic properties may not provide a (typically) semantically meaningful level of atomicity, but they do prevent races on the property from immediately leading to crashes. John. _______________________________________________ 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]
