问题描述
我理解，但我想知道的是：
I understand that the meaning of atomic was explained in What's the difference between the atomic and nonatomic attributes?, but what I want to know is:
Q.除了性能问题之外，在所有地方使用原子属性是否有任何副作用？
似乎答案是否定的，因为iPhone的性能相当快如今。那么为什么这么多人仍在使用非原子？
It seems the answer is no, as the performance of iPhone is quite fast nowadays. So why are so many people still using non-atomic?
甚至 atomic 不保证线程安全，但它仍然比什么都好，对吧？
Even atomic does not guarantee thread safety, but it's still better than nothing, right?
推荐答案
错误 。编写了一些非常复杂的并发程序后，我建议使用相反的。您应该保留 atomic ，以确定何时使用 - 并且您可能无法完全理解这一点，直到您编写并发程序而不使用 atomic 。如果我正在编写多线程程序，我不希望屏蔽编程错误（例如竞争条件）。 我希望并发问题响亮而明显。这样，它们更容易识别，重现和纠正。
Wrong. Having written some really complex concurrent programs, I recommend exactly the opposite. You should reserve atomic for when it truly makes sense to use -- and you may not fully understand this until you write concurrent programs without any use of atomic. If I am writing a multithreaded program, I don't want programming errors masked (e.g. race conditions). I want concurrency issues loud and obvious. This way, they are easier to identify, reproduce, and correct.
相信某些线程安全性优于 none 存在缺陷。该程序是线程安全的，或者不是。使用原子可以使程序的那些方面更容易抵抗与并发相关的问题，但这并不会给你带来太多帮助。当然，可能会有更少的崩溃，但程序仍然毫无疑问是不正确的，它仍将以神秘的方式爆炸。我的建议：如果你不打算花时间学习和编写正确的并发程序，只需将它们保持单线程（如果听起来有点刺耳：它并不意味着苛刻 - 它会让你免于很多麻烦）。多线程和并发是一个庞大而复杂的主题 - 学习在许多领域编写真正正确，长期存在的程序需要很长时间。
The belief that some thread safety is better than none is flawed. The program is either threadsafe, or it is not. Using atomic can make those aspects of your programs more resistant to issues related to concurrency, but that doesn't buy you much. Sure, there will likely be fewer crashes, but the program is still undisputedly incorrect, and it will still blow up in mysterious ways. My advice: If you aren't going to take the time to learn and write correct concurrent programs, just keep them single threaded (if that sounds kind of harsh: it's not meant to be harsh - it will save you from a lot of headaches). Multithreading and concurrency are huge, complicated subjects - it takes a long time to learn to write truly correct, long-lived programs in many domains.
当然，<$ c在某些情况下，可以使用$ c> atomic 来实现线程安全 - 但是使每个访问原子保证没有任何线程安全。同样，非常不寻常（统计学上） atomic 属性本身会使类真正的线程安全，特别是当类的复杂性增加时;更多可能一个具有一个ivar的类只使用原子是真正安全的，而不是一个有5个ivars的类。 atomic 属性是我很少使用的功能（同样，一些非常大的代码库和并发程序）。如果原子是使类真正的线程安全的话，它实际上是一个极端的例子。
Of course, atomic can be used to achieve threadsafety in some cases -- but making every access atomic guarantees nothing for thread safety. As well, it's highly unusual (statistically) that atomic properties alone will make a class truly threadsafe, particularly as complexity of the class increases; it is more probable that a class with one ivar is truly safe using atomics only, versus a class with 5 ivars. atomic properties are a feature I use very very rarely (again, some pretty large codebases and concurrent programs). It's practically a corner case if atomics are what makes a class truly thread safe.
性能和执行复杂性是避免它们的主要原因。与非原子访问相比，以及访问变量的频率和简单性，使用原子非常快。也就是说，原子访问相对于它们执行的任务引入了大量的执行复杂性。
Performance and execution complexity are the primary reasons to avoid them. Compared to nonatomic accesses, and the frequency and simplicity of accessing a variable, use of atomic adds up very fast. That is, atomic accesses introduce a lot of execution complexity relative to the task they perform.
自旋锁是实现原子属性的一种方式。那么，你是否想要一个同步原语，如自旋锁或互斥锁，隐式围绕每个获取和设置，知道它不能保证线程安全吗？我当然不会！在您的实现中使每个属性访问原子可能会消耗大量的CPU时间。只有当你有明确的理由时才应该使用它（也是由dasblinkenlicht + 1提到）。实现细节：一些访问不需要自旋锁来维护 atomic 的保证;它取决于几个方面，例如架构和变量的大小。
Spin locks are one way atomic properties are implemented. So, would you want a synchronization primitive such as a spin lock or mutex implicitly surrounding every get and set, knowing it does not guarantee thread safety? I certainly don't! Making every property access in your implementations atomic can consume a ton of CPU time. You should use it only when you have an explicit reason to do so (also mentioned by dasblinkenlicht+1). Implementation Detail: some accesses do not require spin locks to uphold guarantees of atomic; it depends on several things, such as the architecture and the size of a variable.
那么回答你的问题任何副作用？在TL; DR格式：性能是你注意到的主要原因，而原子保证的适用性以及它对你有用的在你的抽象层次上是非常狭窄的（经常被误解），它会掩盖真正的错误。
So to answer your question "any side-effect?" in a TL;DR format: Performance is the primary reason as you noted, while the applicability of what atomic guarantees and how that is useful for you is very narrow at your level of abstraction (oft misunderstood), and it masks real bugs.
这篇关于在目标C中使用原子属性：任何副作用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！