What does the property "Nonatomic" mean?

Question

What does "nonatomic" mean in this code?

@property(nonatomic, retain) UITextField *theUsersName;

What is the difference between atomic and nonatomic?

Thanks

Solution 1

Take a look at the Apple Docs.

Basically, if you say nonatomic, and you generate the accessors using @synthesize, then if multiple threads try to change/read the property at once, badness can happen. You can get partially-written values or over-released/retained objects, which can easily lead to crashes. (This is potentially a lot faster than an atomic accessor, though.)

If you use the default (which is atomic; there used to be no keyword for this, but there is now), then the @synthesized methods use an object-level lock to ensure that multiple reads/writes to a single property are serialized. As the Apple docs point out, this doesn't mean the whole object is thread-safe, but the individual property reads/writes are.

Of course, if you implement your own accessors rather than using @synthesize, I think these declarations do nothing except express your intent as to whether the property is implemented in a threadsafe manner.

Solution 2

After reading so many Articles and StackOverflow posts, and having made demo apps to check Variable property attributes, I decided to put all the attributes information together

1. atomic //default
2. nonatomic
3. strong=retain //default
4. weak= unsafe_unretained
5. retain
6. assign //default
7. unsafe_unretained
8. copy
9. readonly
10. readwrite //default

so below is the detailed article link where you can find above mentioned all attributes, that will definitely help you. Many thanks to all the people who give best answers here!!

Variable property attributes or Modifiers in iOS

1. atomic
   • Atomic means only one thread access the variable (static type).
   • Atomic is thread safe.
   • But it is slow in performance.
   • Atomic is default behavior.
   • Atomic accessors in a non garbage-collected environment (i.e. when using retain/release/autorelease) will use a lock to ensure that another thread doesn't interfere with the correct setting/getting of the value.
   • it is not actually a keyword.

Example :

@property (retain) NSString *name;

@synthesize name;

2. nonatomic
   • Nonatomic means multiple thread access the variable (dynamic type).
   • Nonatomic is thread unsafe.
   • But it is fast in performance.
   • Nonatomic is NOT default behavior; we need to add nonatomic keyword in property attribute.
   • it may result in unexpected behavior, when two different process (threads) access the same variable at the same time.

Example:

@property (nonatomic, retain) NSString *name;

@synthesize name;

Solution 3

In addition to what's already been said about threadsafeness, non-atomic properties are faster than atomic accessors. It's not something you usually need to worry about, but keep it in mind. Core Data generated properties are nonatomic partially for this reason.

Solution 4

In a multi-threaded program, an atomic operation cannot be interrupted partially through, whereas nonatomic operations can.

Therefore, you should use mutexes (or something like that) if you have a critical operation that is nonatomic that you don't want interrupted.

Solution 5

If you specify "atomic", the generated access functions have some extra code to guard against simultaneous updates.

View more solutions

Comments

[Admin]

Sorry, forgot to specify this is in Objective-c (cocoa)

[Vijayendra]

Please also read this link - stackoverflow.com/questions/588866/…

[Fattie]

For anyone reading this, for 2014 it's important to realise a lot of this information is hugely out of date. There is, in a word, no reason ever to use nonatomic and it's essentially wrong to ever use it, for any reason. it's ancient history. Nonatomic means "thread unsafe mode" and is (in a word) now totally irrelevant. Some comments here stackoverflow.com/q/23977765/294884

[Nick Turner]

I would disagree with the "non relevant" statement. If the value changes Rarely and as the example in Apple doc is last name. It changes once then using an atomic hint is a waste of resources involved since the checks are not needed.

[Grigori Jlavyan]

Here is answer stackoverflow.com/a/32942413/1961064

[PapillonUK]

I like this answer - less confusing, simpler and more complete that those found elsewhere!

[David Rönnqvist]

Are you sure it's not the opposite? Atomic properties are safe but nonatomic properties are not safe. Last time I checked it was like that :P

[Wish]

Really great one and less confusing (+1) but can you please tell that why non-atomic potentially lot faster than an atomic accessor ?

[Max Steinmeyer]

@Wish Non-atomic accessors can be faster because to prevent other threads from reading/writing at the same time, you need to hold a mutex or do some other low-level tricks which cost CPU time. If you're using a lock, you can also end up blocking on other threads, which takes time, too.

[Wish]

@Jesse Thanks for your response.

[Johan Karlsson]

IMHO: In order to get any upvotes, you need to be more specific and spend some time on writing your answer.

[Rob]

What would be the best way to implement the accessors to be thread safe?

[Max Steinmeyer]

@Rob You might want to ask a new question about that.

[NSPratik]

Jesse Rusak, Read the following paragraph found on Apple document at the link you provided. See my next comment:

[NSPratik]

Note:Consider an XYZPerson object in which both a person’s first and last names are changed using atomic accessors from one thread. If another thread accesses both names at the same time, the atomic getter methods will return complete strings (without crashing), but there’s no guarantee that those values will be the right names relative to each other. If the first name is accessed before the change, but the last name is accessed after the change, you’ll end up with an inconsistent, mismatched pair of names..

[NSPratik]

It says, in case of atomic, there’s no guarantee that those values will be the right names relative to each other. If the first name is accessed before the change, but the last name is accessed after the change, you’ll end up with an inconsistent, mismatched pair of names. That means, your answer is inverted between atomic and nonatomic. Correct me if I understood something wrong.

[Max Steinmeyer]

@Pratik Sorry, that's not correct. The quote you show is saying exactly the same thing I did: that making a property atomic avoids crashes while accessing individual properties but doesn't ensure that the object as a whole (i.e. accessing separate properties like the first and last names) is going to do the right thing.

[NSPratik]

Thanks Jesse Rusak. I am clear now. Can we say atomic is thread-safe ? Also if my App is multi-threaded, what accessor should be used ? atomic or non-atomic ?

[Max Steinmeyer]

@Pratik That's hard to answer in general; if you have specifics, you might want to start a new question.