Does atomic really mean anything for a synthesized primitive?

Question

In Android, I could safely get and change primitive types from different threads. I used this to exchange data between my OpenGL drawing cycle and user preferences that were changed in the main Android UI thread. By storing each parameter in a primitive type and making each independent of the other values, it would be thread safe to change all these variables without using locks or the synchronize keyword.

Is this also true in Objective-C? I read that putting an atom in a variable essentially makes the synthesized getter and setter use locks similar to using synchronized methods in Java. And I read that the reason for this is that the object does not partially change while it is being read by another thread.

But are primitive types safe from partial modification since they are in Java? If so, it looks like I could use my previous Java paradigm to exchange data between threads. But then the atom keyword would be meaningless for the primitive, the right one?

I also read that a more reliable and faster solution than using atomic variables is to copy objects before using them if they are accessed from multiple threads. But I'm not sure how to do this. Did you fail to modify the non-nuclear object while copying, thereby damaging the copy?

Answer 1

Primitive types do not guarantee that they can be partially modified, because modifications to primitive types are not guaranteed to be atomic in C and Objective-C are inherited from there. C guarantees only points in the sequence and does not require that the processing between two points in the sequence be atomic - the rule is that each complete expression is a point in the sequence.

In practice, modifying primitives is often a two-step process; modification is made in the register and then written to memory. It is very unlikely that the record itself will not be atomic, but there is also no guarantee when it will occur in comparison with the modification. Even with volatile qualifications, the only guarantees are provided in terms of sequence points.

Apple provides some C functions for atomic activities through OSAtomic.h , which are directly mapped to specialized atomic instructions offered by CPUs for implementing concurrency mechanisms. Perhaps you could use one of them more directly than through a crazy mutex.

Common patterns in Objective-C:

• immutable objects and functional transformations - there are also reasons for memory management, but partly why NSString , NSArray , etc., in particular, differ from NSMutableString , NSMutableArray , etc.
• serial mail queues, which can be combined with copy-modification-replacement, copying in the queue, going to another place to change, and then return to the queue for replacement;
• such @synchronized s, NSConditionLock or other explicit synchronization mechanisms that are appropriate.

The main thread itself is a sequential dispatch queue, so you can completely ignore the concurrency problem if you limit yourself.

Answer 2

Atomic synthesized @properties are immune to parallel partial updates. Access methods will use locking, if necessary, in this architecture.

In general, primitive types in C are not necessarily safe for concurrent partial updates.

Answer 3

I do not believe that you can partially modify a primitive type, this part of what makes them primitive. You either modify it or not. In this sense, I would say that they are thread safe.

You are right when you say that the atom keyword will be meaningless for the primitive type.

Someone has already taken a hit here: Objective-c properties for primitive types