1

I have read a lot of topics about the atomic and nonatomic attributes in Objective-C, and I understand that atomic means thread safe and therefore nonatomic is faster. But the main problem is that I don't understand what are threads at all and how they are being expressed in the code. Are they kind of methods? And I also noticed that most of the properties are nonatomic, why is that? I saw that threads may access setter or getter of a property simultaneously, how is this possible and how is this being expressed in the runtime? Also as a newbie programmer should I prefer atomic or nonatomic?

I have searched in a lot of questions regarding this but none has actually answered my question.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Ani
  • 33
  • 3
  • 2
    "atomic" != "thread-safe", compare http://stackoverflow.com/questions/588866/atomic-vs-nonatomic-properties. – Martin R Nov 09 '13 at 19:53
  • 2
    About threads in general, perhaps start by reading Apple's ["Threading Programming Guide"](https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Multithreading/Introduction/Introduction.html). – Martin R Nov 09 '13 at 19:55
  • 1
    This is a lot of confusion jumbled into one question; that's why you can't find one single answer. Threads are not specific to ObjC or Cocoa. The question Martin has linked should answer the bits you are asking about that are specific to declared properties. – jscs Nov 09 '13 at 19:56
  • I saw the question Martin mentioned but the answer is very confusing me because he is talking about threads, and I don't understand what is thread, and my main question is how threads are being expressed in the code and runtime. – Ani Nov 09 '13 at 20:04

2 Answers2

0

As Martin points out, people generally don't rely upon the atomic qualifier because that does not (generally) ensure thread-safety. The critical observation is that one must properly synchronize changes to variables as discussed in the Synchronization section of that Threading Programming Guide that Martin pointed you to.

So, in answer to your question, you probably should generally employ nonatomic (it's a little faster than atomic), but then determine which of the various synchronization techniques (serial queue, NSLock, NSRecursiveLock, @synchronized, etc.) as part of your broader thread-safe system design. In some cases, atomic might be part of that solution (as the Synchronization - Atomic Operations section of the Threading Programming Guide points out that atomic operations are "a simple form of synchronization that work on simple data types"), but as you're often dealing with objects, not simple data types, then atomic is likely to be insufficient.

As an aside, if you're diving into multi-threaded code for the first time, I might also suggest that you check out the Concurrency Programming Guide which talks about a slightly easier way to write multithreaded code without needing to get into the weeds of NSThread. You can either use dispatch queues (Grand Central Dispatch) and operation queues (NSOperationQueue).

Some additional references:

There are lots of other WWDC videos on the topic, but those might be two good ones to start with.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
0

what are threads at all and how they are being expressed in the code.

Seriously, this is a big topic. So here are some thought and a specific answer to last question.

Actually, not all programs need concurrency, so I'd say if you haven't found a requirement for it in your application, you're free to relax. Then it won't matter if your properties are atomic or not.

Also as a newbie programmer should I prefer atomic or nonatomic?

As a newbie programmer, I'd say leave them as default. If they are fully synthesized, compiler will honestly synthesize an atomic getter and setter for you. There's nothing wrong with that, and certainly you shouldn't "try to make them faster" until you profiled the application and found that to be an issue.

If you provide methods for your properties yourself, your properties will actually be nonatomic, but I'm not sure marking them as such is worth the effort. Try to do that in code that is likely to be re-used by other people.

In some cases the compiler forces you to declare that the properties are nonatomic (when you pair a custom setter with synthesized getter or vice-versa). Well, in those cases go ahead and do that.

ilya n.
  • 18,398
  • 15
  • 71
  • 89