The Concept of “Atomic” in Objective-C

We all live in a Swift world now, right? Well, usually. But for many tasks (such as unit testing, frameworks, cryptography, and so on), I still often find myself using Objective-C. I have a feeling that Objective-C is going to be with us for awhile. Some of the least understood concepts in Objective C are the way that elements of data encapsulation (ahem, such as variables) are designated with words such as: atomic, non-atomic, strong, and weak.

Sometimes in life, we just “know” how something works by the very act of using it repeatedly. These terms are like that. But if asked to articulate them, it can be a challenge. I like challenges, so I am going to write a few posts in which I articulate these concepts.

For this post, I will examine what “atomic” means. Here it comes:

Just like a stove having different burners so that multiple things can be cooking at the same time, it’s often helpful to have a computer processor do several things at once. This is known as threading. Every program has a main thread. Now imagine we write a program which downloads an image. If we download the image in the main thread, then everything else in the program will be frozen until the image is finished downloading. However, if we place the action of downloading the image into its own thread, then that can take place while we are using other features of the program.

Now suppose the main thread of our program can get and set a variable with a name for the image. Now imagine there is also a second thread that can set or get the same variable for image name. If we make the variable “atomic” then this will ensure that the entire name is set or retrieved.

This play by play will help to visualize what would happen WITHOUT it being atomic:

THREAD 1[Set variable to bob.jpg]
THREAD 1(Write b)
THREAD 1(Write o)
THREAD 2[Set variable to lucy.png]
THREAD 2(Write l)
THREAD 1(Write b)
THREAD 1(Write .)
THREAD 2(Write u)
THREAD 1(Write j)
THREAD 2(Write c)
THREAD 1(Write p)

… and so on. We end up with bolb.ujcpgy.png (which is some mix of “bob.jpg” and “lucy.jpg” because each thread was adding to the variable at the same time.) However, if we used “atomic” then there would be none of this intermixing. We could be assured the variable was either bob.jpg or lucy.png.

Thread 2’s request is forced to wait until “bob.jpg” is complete, and then it changes the value to “lucy.png” without interruption.

My source? The mother ship: “This means that the synthesized accessors ensure that a value is always fully retrieved by the getter method or fully set via the setter method, even if the accessors are called simultaneously from different threads.”

I have dealt with a somewhat similar issue in Unity3D while writing text one character at a time to the screen for a “typewriter effect.” In that case, a single label was being written to from a method that was called by a.) a timer and b.) a frame refresh. This doubling up resulted in repeating and mixed characters. For example, “the end” came out as “ttthheeee ennnnd.” For me, as I articulate the concept of “atomic” values, that Unity3D typewriter effect, served as a sort of slow motion dramatization of how setting data to a single resource (the label) from two callers can result in intermixed data over time. Atomic solves that issue for encapsulated data in Objective-C.