<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Nov 30, 2016, at 8:33 AM, Jiho Choi via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">I am new to Swift, and I have several questions about how ARC works in Swift.</div><div class=""><br class=""></div><div class="">1. I read from one of the previous discussions in the swift-evolution list (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html</a>) that ARC operations are currently not atomic as Swift has no memory model and concurrency model. Does it mean that the compiler generates non-atomic instructions for updating reference counts (e.g. using incrementNonAtomic() instead of increment() in RefCount.h)?</div></div></div></blockquote><div><br class=""></div>No. We have the ability to do non-atomic reference counting as an optimization, but we only trigger it when we can prove that an object hasn't escaped yet. Therefore, at the user level, retain counts are atomic.</div><div><br class=""></div><div>Swift ARC is non-atomic in the sense that a read/write or write/write race on an individual property/variable/whatever has undefined behavior and can lead to crashes or leaks. This differs from Objective-C ARC only in that a (synthesized) atomic strong or weak property in Objective-C does promise correctness even in the face of race conditions. But this guarantee is not worth much in practice because a failure to adequately synchronize accesses to a class's instance variables is likely to have all sorts of other unpleasant effects, and it is quite expensive, so we decided not to make it in Swift.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">2. If not, when does it use non-atomic ARC operations? Is there an optimization pass to recognize local objects?</div><div class=""><br class=""></div><div class="">3. Without the concurrency model in the language, if not using GCD (e.g. all Swift benchmark applications), I assume Swift applications are single-threaded. Then, I think we can safely use non-atomic ARC operations. Am I right?</div></div></div></blockquote><div><br class=""></div>When we say that we don't have a concurrency model, we mean that (1) we aren't providing a more complete language solution than the options available to C programmers and (2) like C pre-C11/C++11, we have not yet formalized a memory model for concurrency that provides formal guarantees about what accesses are guaranteed to not conflict if they do race. (For example, we are unlikely to guarantee that accesses to different properties of a struct can occur in parallel, but we may choose to make that guarantee for different properties of a class.)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">4. Lastly, is there a way to measure the overhead of ARC (e.g. a compiler flag to disable ARC)?</div></div></div></blockquote><div><br class=""></div></div>No, because ARC is generally necessary for correctness.<div class=""><br class=""></div><div class="">John.</div></body></html>