Atomic properties vs thread-safe in Objective-C

Question

In most of the discussions I've read, it indicates that making a property atomic does not guarantee it to be thread-safe, it just guarantees that the value returned won't be garbage as a result of one object writing to it and another trying to read it at the same time.

I understand this isn't thread-safe as a third object could be writing it and while the object accessing it wouldn't get garbage back, it's not entirely certain which value it will get back as multiple objects are writing to it at the same time, and it may get any of their values.

So when we say it won't return garbage, would garbage be in the sense that if an object was non-atomic and an object tried to access it while another was writing to it, it might get the result back mid-write, and only get a partial, incomplete version of the change brought about by the write? Is this what "garbage" means in this sense, and what atomic properties help to prevent?

Answer 1

An atomic property in Objective C guarantees that you will never see partial writes. When a @property has the attribute atomic it is impossible to only partially write the value. The setter is like that:

- (void)setProp:(NSString *)newValue {
    [_prop lock];
    _prop = newValue;
    [_prop unlock];
}

So if two threads want to write the value @"test" and @"otherTest" at the same time, then at any given time the property can only be the initial value of the property or @"test" or @"otherTest". nonatomic is faster but the value is a garbage value and no partial String of @"test"/@"otherTest" (thx @Gavin) or any other garbage value.

But atomic is only thread-safe with simple use. It is not garantueed. Appledoc says the following:

Consider an XYZPerson object in which both a person’s first and last names are changed using atomic accessors from one thread. If another thread accesses both names at the same time, the atomic getter methods will return complete strings (without crashing), but there’s no guarantee that those values will be the right names relative to each other. If the first name is accessed before the change, but the last name is accessed after the change, you’ll end up with an inconsistent, mismatched pair of names.

I never had a problem using atomic at all. I designed the code that way, that there is not problem with atomic properties.