Atomic uses atomicity to keep threads safe. Is that really the case?
Nonatomic memory management semantics are non-atomic. A non-atomic operation is inherently thread-safe. Atomic operations are atomic, but that doesn’t mean they are thread-safe. When nonatomic, property setters and getters are nonatomic, so when multiple threads read and write to a property at the same time, the end result of the property is unpredictable. When atomic is used, even though reads and writes to attributes are atomic, threading errors can occur: when thread A writes, reads or writes from other threads wait for that 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. It is important to note that what the atomic says is thread-safe only guarantees thread-safe access to getter and setter methods, not thread-safe access to the entire object. As shown below:
@property(atomic,strong)NSMutableArray *arr;
If one thread cycles through reading data and one thread cycles through writing data, then you’re definitely going to have a memory problem because it has nothing to do with setters and getters. Using [self.arr objectAtIndex:index] is not thread-safe. A good solution is to lock.
Atomic is said to be about 20 times slower than nonatomic. Generally, if conditions permit, we can let the server to lock the operation.
From: www.cnblogs.com/hlgbys/p/54…