> On May 1, 2017, at 8:54 AM, John McCall <[email protected]> wrote: >> 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.
Another influence was Objective-C garbage collection. GC was assumed to be The Future, and atomic properties are cheap when you have GC. -- Greg Parker [email protected] <mailto:[email protected]> Runtime Wrangler
_______________________________________________ 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]
