Why is "atomic" a default @property qualifier in Objective C when I find myself using nonatomic 100% of the time?

Question

In my few years as an iOS developer I don't think I've ever used atomic on a property. If I can see potential race conditions or data integrity issues due to threading, using atomic on a @property wouldn't ever help. I use conventional transaction/unit-of-work thread safety techniques (using mechanisms locks, semaphores or whatever).

Does anyone have (or know of) any practical examples of where atomic is used? (I'd love to see some actual/practical code examples)

After writing nonatomic for maybe the billionth time, I'm also wondering why Apple have decided to make atomic the default.

Answer 1

As for the first problem you're having, maybe it's because

Although “atomic” means that access to the property is thread-safe, simply making all the properties in your class atomic does not mean that your class or more generally your object graph is “thread safe”—thread safety cannot be expressed at the level of individual accessor methods.

As for why apple makes it atomic by default, I don't think there is any good reason, it was simply a bad design decision. Guys at the WWDC sessions repeatedly encouraged people to use nonatomic wherever you can to eliminate the performance impact.

Answer 2

It's worth noting that under garbage collection, almost all synthesized accessors are inherently atomic—there would be no difference between the atomic and nonatomic version, since the simple assignment of a pointer is all that's required in both cases. Since you really can't make a nonatomic synthesized accessor under garbage collection, they may have decided that it made more sense to just have things atomic by default.

I don't have any evidence that this was the reasoning behind the decision, but it makes sense to me.

(In case you're curious, there are still cases under garbage collection where simple assignment is nonatomic—this happens when the value is larger than the word size of the process. In practice, that only happens with structs.)

Edit: Added sources

More information on the atomicity of synthesized properties under garbage collection can be found in The Objective-C Programming Language -> Declared Properties -> Performance and Threading, where it says "In a garbage collected environment, most synthesized methods are atomic without incurring this overhead." The inherent atomicity is mentioned more explicitly in the 2008 WWDC session 420 "Using Garbage Collection with Objective-C", around the 29 minute mark.

Answer 3

In two words - thread safety. Most of the applications we write on a regular basis are fairly simple and as such are actually going to benefit from not having the additional locks.

---

From Apple's The Objective-C Programming Language:

Properties are atomic by default so that synthesized accessors provide robust access to properties in a multi-threaded environment—that is, the value returned from the getter or set via the setter is always fully retrieved or set regardless of what other threads are executing concurrently. For more details, see “Performance and Threading.”

If you do not specify nonatomic, then in a reference counted environment a synthesized get accessor for an object property uses a lock and retains and autoreleases the returned value—the implementation will be similar to the following:

[_internal lock]; // lock using an object-level lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;

If you specify nonatomic, then a synthesized accessor for an object property simply returns the value directly.

Answer 4

When Apple first introduced the concept of properties, there was a big argument about whether atomic or nonatomic should be the default and the atomic people won.

I think the reasoning is that in a threaded environment, unless the property is atomic, you can't guarantee that the pointer it returns is valid. A non atomic getter would be implemented something like this

-(MyObj*) someProperty
{
     return someInstVar;
}

It's possible that some other thread could deallocate the object pointed to by someInstVar after the pointer has been placed in the register for returning but before the caller has had time to retain it. Even this is no good:

-(MyObj*) someProperty
{
     return [[someInstVar retain] autorelease];
}

because some other thread could dealloc someInstVar just before the retain count is incremented.

The only way to safely return the pointer in a multithreaded environment is something like this:

-(MyObj*) someProperty
{
     @synchronized(self)
     {
         return [[someInstVar retain] autorelease];
     }
}

and also to synchronise the setter too.

However, the problem with that is that the lock is very expensive (in reality they used something much lighter than @synchronized but it's still expensive) so everybody was using nonatomic anyway and just making all the properties atomic doesn't confer thread safety in general so other techniques are required anyway and they tend to obviate the problem I discussed above.

There are plenty of people who think the wrong decision was made about what the default should be, but it can't be changed now for backwards compatibility. I find myself typing nonatomic without even thinking now.

Answer 5

Atomic calls are calls that cannot be interrupted. The entire call must be executed.

Updating something like a shared counter variable would be something that could be atomic because you wouldn't want two processes trying to access the variable at the same time. The actions would need to be executed "atomically".

There is a lot of useful information in this SO post: Atomic vs nonatomic properties as to what the differences are and the thread safety issues of atomic vs nonatomic.