使用 NSOperationQueue (iPhone) 时模型类中的非原子属性？
我有一个带有 NSMutableData ivar 的自定义模型类，它将由自定义 NSOperation 子类（使用 NSOperationQueue）访问。我认为我可以通过使用依赖项保证从多个 NSOperations 对 ivar 的线程安全访问，并且我可以通过等待 Q 完成所有操作来保证我不会从其他代码（比如我的主应用程序线程）访问 ivar 。
我应该使用非原子属性规范，还是保留其原子性？对性能有显着影响吗？
I have a custom model class with an NSMutableData ivar that will be accessed by custom NSOperation subclasses (using an NSOperationQueue). I think I can guarantee thread-safe access to the ivar from multiple NSOperations by using dependencies, and I can guarantee that I don't access the ivar from other code (say my main app thread) by waiting until the Q has finished all operations.
Should I use a nonatomic property specification, or leave it atomic? Is there a significant impact on performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
安德鲁，这是否重要取决于你在做什么。如果您的操作将电影上传到 youtube，并且每个操作都需要读取数据一次，那么它不会产生丝毫差异 - 只需将其保留为原子即可。
否则，您需要进行分析以查看其是否重要。如果您确定（您听起来不太确定） NSMutableData 永远不会同时从两个或多个线程访问（无论您如何执行，锁定，屏障或只是等待），那么您就不需要它成为原子的。
Andrew, whether it's significant depends on what you are doing. If your Operations are uploading movies to youtube and each operation needs to read the data once then it doesn't make the slightest bit of difference - just leave it as atomic.
Otherwise you need to profile to see if it is significant. If you are sure (you don't sound that sure) that the NSMutableData will never be accessed from two or more threads simultaneously (however you do it, lock, barriers, or just waiting) then you don't have a need for it to be atomic.
过早的优化是万恶之源。
让它保持原子状态，直到您确定存在性能问题。
Premature optimisation is the root of all evil.
Leave it atomic until you find out for sure that there is a performance issue.
如果它是一个可变对象，那么你最大的敌人是并发突变，而不是不一致的属性访问。
If it's a mutable object then your biggest enemy is concurrent mutation, not inconsistent property access.