Wednesday, June 20, 2018
10:51:48 PM
Users online: 0   You are here >> Home > Programming

Forums | Programming Forums search
Forum FAQ
objective C question - what is atomic?
16/4/08 7:08:21 PM
Hello, studying objective C, things are coming pretty easy. Nice language, really. However, having trouble figuring out exactly what "atomic" vs. "non-atomic" means in the context of setting property attributes.

As in:

@property (nonatomic) myObject *object;

The documentation says:

The effect of the nonatomic attribute depends on the environment. By default, the synthesized accessors are atomic. In a managed memory environment, guaranteeing atomic behavior requires the use of a lock; moreover a returned object is retained and autoreleased. If such accessors are invoked frequently, this may have a significant impact on performance. In a garbage collected environment, most synthesized methods are atomic without incurring this overhead.

It is important to understand that the goal of the atomic implementation is to provide robust accessors—it does not guarantee correctness of your code. Although “atomic” means that access to the property is thread-safe, simply making all the properties in your class atomic does not mean that your class or more generally your object graph is “thread safe”—thread safety cannot be expressed at the level of individual accessor methods. For more about multi-threading, see Threading Programming Guide.

So clearly it has to do with threading issues. I've experience with multithreaded programming in C++ using posix threads (dealing with semaphores, mutex's, etc). So is an atomic property one that is accessed using thread-safe techniques (and is therefore slower, but safe) while nonatomic properties are accessed without regard to threading issues (and therefore faster, but more dangerous)?

But again, what exactly is an atom?

By the way, I found this forum by searching on google... "atomic" came up naturally... heh...

Thanks for any help!


16/4/08 8:10:49 PM

'atomic' means it cannot be broken down.
In OS/programming terms an atomic function call is one that cannot be interrupted - the entire function must be executed, and not swapped out of the CPU by the OS's usual context switching until its complete. I'm not sure how much you know about OS's, but just in case you didnt know: since the CPU can only do one thing at a time, the OS rotates access to the CPU to all running processes in little timeslices, to give the illusion of multitasking. The CPU scheduler can(and does) interrupt a process at any point in its exceution - even in mid function call. So for actions like updating shared counter variables where two processes could try to update the variable at the same time, they must be executed 'atomically', ie each update action has to finish in its entireity before any other process can be swapped onto the CPU.

So id be guessing that atomic in this case means the attribute reader methods cannot be interrupted - in effect meaning that the variable(s) being read by the method cannot change value part way through because some other thread/call/function gets swapped onto the CPU.

Edited by dave_blob: 16/4/2008 08:19:54 PM

Your comeback shames me

You exist. You are born and you die. That's it.
What matters is life before death - enjoy your time here, be nice to others and have some fun.

17/4/08 9:23:10 AM
wow. great explanation. you answered it exactly... I was sort of thinking in that direction since I've done multithreaded programming a bit and understand how to manage shared data between threads. However, it wasn't clear nor was I confident in my understanding. This is relevant even in non-multithreaded apps if you are dealing with class-shared static variables that any instance could access, etc.



Forums | Programming