Let’s talk about atomicity without language:

Atomicity means that the operations of a thing are indivisible and either all or none of them happen.

For example 🌰 :(From some great god who wishes to remain anonymous)

A bank transfer is an atomic operation. Zhang SAN goes to the bank and transfers 1000 yuan to Li Si. Zhang SAN used to have 2000 yuan in his card, and Li Si used to have 2000 yuan in his card, so the transfer procedure should be as follows:

So back to our OC :(this is our objective-c)

Looking at our atomic and nonatomic, we generally understand thread-safe and non-thread-safe, and I think that’s just describing atomicity ona linguistic level.

Since atomic describes attribute assignment, which involves many other operations such as accessing objects, assigning values, etc., natomic guarantees the integrity of the assignment process without interference from other threads, either succeeding or failing.

Here’s a question: Why is it that atomic is sometimes unable to ensure thread safety?

My conclusion: with atomic modifications, the setter and getter methods for this property are thread-safe, but not necessarily thread-safe for the entire object.

1. Why setter and getter methods are thread-safe?

Thread locks in OC: Thread locks in OC: thread locks in OC

// getter
id objc_getProperty(id self.SEL _cmd, ptrdiff_t offset, BOOL atomic) {
   // ...
   if(! atomic)return *slot;

   // Atomic retain release world
   spinlock_t& slotlock = PropertyLocks[slot];
   slotlock.lock();
   id value = objc_retain(*slot);
   slotlock.unlock();
   // ...
}

// setter
static inline void reallySetProperty(id self.SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
   // ...
   if(! atomic) { oldValue = *slot; *slot = newValue; }else {
       spinlock_t& slotlock = PropertyLocks[slot];
       slotlock.lock();
       oldValue = *slot;
       *slot = newValue;        
       slotlock.unlock();
   }
   // ...
}
Copy the code

2. Why is it that atomic cannot guarantee the thread-safety of the entire object?

NSArray @property(atomic)NSArray *array we use atomic modifier. Adding and removing arrays is not thread-safe. This is because arrays are very special. The other part is the memory part that he’s pointing to. Atomic limits only the &array part and has no restrictions on the objects it points to. By the way, I am totally wrong ！！！！

2. When thread A performs A write operation, the read or write operations of other threads wait for the operation. When thread A finishes writing, thread B writes, and then when thread A needs to read, it gets the value in thread B, which breaks thread safety. If thread C releases the property before thread A reads, it will crash. So using atomic alone does not make the thread safe, we need to add locks to the thread to make it safe. Personally, I think this is a bit of a bar essence meaning, atomic also tube to your method outside to ？？？？？ But the interview somebody else asks you still have to answer so, want rigorous!! .

Personal understanding of the problem we put forward more, discussion in order to learn.

IOS Atomic Objects are thread unsafe and the difference between them and nonatomic objects (the name is very unusual 😄, but the unsafe is caused by the reference nature of OC objects, see below)