views:

115

answers:

3

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?

+1  A: 

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.

mustISignUp
A: 

Premature optimisation is the root of all evil.

Leave it atomic until you find out for sure that there is a performance issue.

JeremyP
A: 

If it's a mutable object then your biggest enemy is concurrent mutation, not inconsistent property access.

Graham Lee
Yes, I agree -- thanks for the clarification! That is what I am trying to protect against: concurrent mutation. So... any idioms you know of in ObjC for that?
Andrew B.
The general answer is to make the property immutable, and provide synchronized methods (or an operation queue) as the only way to make changes. How that works in your case really depends on your own application's needs.
Graham Lee