0

I've already read through several explanation on the differences between atomic and nonatomic. Like in this link, it says:

With "atomic", the synthesized setter/getter will ensure that a whole value is always returned from the getter or set by the setter, regardless of setter activity on any other thread. That is, if thread A is in the middle of the getter while thread B calls the setter, an actual viable value -- an autoreleased object, most likely -- will be returned to the caller in A.

In nonatomic, no such guarantees are made. Thus, nonatomic is considerably faster than "atomic".

Nonatomic qualifier may cause access error when using setter and getter at the same time. Then what's the point of using it, although it's faster than atomic?

Community
  • 1
  • 1
Brucewang7777
  • 29
  • 7
  • you already have the answer, if you know your usage is safe then why would you want a slower and more resource intensive accessor implementation... – Wain Jul 19 '16 at 13:53
  • 1
    refer [dasblinkenlight's answer](http://stackoverflow.com/questions/17571338/why-properties-are-always-said-to-be-made-nonatomic-in-objective-c) – Ketan Parmar Jul 19 '16 at 13:56
  • @Wain According to the "possible duplicated answers", they would rather choose using nonatomic to save time than to use atomic to make it safer. Which is the first priority, safety or speed? – Brucewang7777 Jul 19 '16 at 15:59
  • safer is based on knowledge - if you know that something will only be accessed by a single thread then go for the fast option. also, often protecting single accessors from multi-threaded access doesn't actually offer the safety you need as it's parter of a larger composite operation... – Wain Jul 19 '16 at 16:37

1 Answers1

0

Performance. If you declare properties as atomic, the accessors will use locks to ensure that values are fully retrieved and set. If you don't need this - you are sure that only one thread will have access to this variable , you're incurring a performance penalty for those locks without getting a benefit. So it's up to you to decide where you need a lock on object or not.

l.vasilev
  • 926
  • 2
  • 10
  • 23