2

After reading this answer I am very confused.

Some says atomic is thread safe and some are saying nonatomic is thread safe.

What is the exact answer of this.

Community
  • 1
  • 1
user5214391
  • 69
  • 6
  • 2
    Be aware that making a property atomic is not all that is required for thread safety. An atomic reference to an NSMutableArray will make the reference thread safe but not the actual array. – Paulw11 Aug 31 '15 at 08:35

4 Answers4

1

Thread unsafety of operations is caused by the fact that an operation can be divided into several suboperations, for example:

a = a + 1

can be subdivided into operations

load value of a
add 1 to the loaded value
assign the calculated value to a.

The word "Atomic" comes from "atom" which comes from greek "atomos", which means "that which can't be split". For an operation it means that it is always performed as a whole, it is never performed one suboperation at a time. That's why it is thread safe.

TL;DR Atomic = thread safe.

Big warning: Having properties atomic does not mean that a whole function/class is thread safe. Atomic properties means only that operations with the given properties are thread safe.

Sulthan
  • 118,286
  • 20
  • 194
  • 245
1

Obviously, nonatomic certainly isn’t thread safe. More interestingly, atomic is closer, but it is insufficient to achieve “thread safety”, as well. To quote Apple’s Programming with Objective-C: Encapsulating Data:

Note: Property atomicity is not synonymous with an object’s thread safety.

It goes on to provide an example:

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.

This example is quite simple, but the problem of thread safety becomes much more complex when considered across a network of related objects. Thread safety is covered in more detail in Concurrency Programming Guide.

Also see bbum’s Objective-C: Atomic, properties, threading and/or custom setter/getter.

The reason this is so confusing is that, in fact, the atomic keyword does ensure that your access to that immediate reference is thread safe. Unfortunately, when dealing with objects, that’s rarely sufficient. First, you have no assurances that the property’s own internal properties are thread safe. Second, it doesn’t synchronize your app’s access to the object’s individual properties (such as Apple’s example above). So, atomic is almost always insufficient to achieve thread safety, so you generally have to employ some higher-level degree of synchronization. And if you provide that higher-level synchronization, adding atomicity to that mix is redundant and inefficient.

So, with objects, atomic rarely has any utility. It can be useful, though, when dealing primitive C data types (e.g. integers, booleans, floats). For example, you might have some boolean that might be updated in some other thread indicating whether that thread’s asynchronous task is completed. This is a perfect use case for atomic.

Otherwise, we generally reach for higher-level synchronization mechanisms for thread safety, such as GCD serial queues or reader-writer pattern (... or, less common nowadays, locks, the @synchronized directive, etc.).

Rob
  • 371,891
  • 67
  • 713
  • 902
0

As you can read at developer.apple you should use atomic functions for thread savety.

You can read more about atomic functions here: Atomic Man page

In short: Atomic ~ not splittable ~ not shared by threads

SWiggels
  • 1,674
  • 1
  • 15
  • 30
  • The link i gave some one mention that atomic is read/write safe but not thread safe is this wrong @SWiggles – user5214391 Aug 31 '15 at 08:14
  • From documentation: `Atomic operations are a simple form of synchronization that work on simple data types. The advantage of atomic operations is that they do not block competing threads. For simple operations, such as incrementing a counter variable, this can lead to much better performance than taking a lock.` For full thread saveness you have to lock your code or use threadsave methods only. – SWiggels Aug 31 '15 at 08:38
-1

As is mentioned in several answers to the posted question, atomic is thread safe. This means that getter/setter working on any thread should finish first, before any other thread can perform getter/setter.

Shamas S
  • 7,237
  • 8
  • 44
  • 58
  • 1
    The link i gave some one mention that atomic is read/write safe but not thread safe is this wrong – user5214391 Aug 31 '15 at 08:14
  • @user5214391 I think the answer you're referring to is by user:bbum. S/he explains the answer in a comment saying 'thread safety can only be really expressed at the model level, not the individual accessor. Think of firstName/lastName, thread A retrieves firstName, thread B sets lastName, thread A retrieves lasName, thread B sets firstName. A now has a mismatched set of names; atomicity can't protect against that without introducing transaction atomicity which is a model level issue.' – Shamas S Aug 31 '15 at 08:23
  • @user5214391 - Yes, “atomic is read/write safe but not thread safe” is, indeed, a nice concise summary. Atomicity ensures that the access to the value or pointer to the object is retrieved/updated safely, but does not ensure that the object, itself, nor your subsequent interaction with it, is thread safe. – Rob May 06 '19 at 16:43