-3

I have gone through many answers about atomic and non-atomic properties. But I'm not able to understand whether atomic properties are thread safe? Please explain it with an example.

aksh1t
  • 5,410
  • 1
  • 37
  • 55
Dhiman Ranjit
  • 81
  • 2
  • 12
  • In what way is http://stackoverflow.com/questions/21098494/atomic-properties-vs-thread-safe-in-objective-c not sufficient? – luk2302 Nov 15 '15 at 18:27
  • @bbum wow, you can mark as duplicate of multiple questions :O – luk2302 Nov 15 '15 at 18:54
  • @luk2302: Duplicate of questions with answers totallling several thousand reputation points. – gnasher729 Nov 15 '15 at 19:31
  • As [Apple says](https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html#//apple_ref/doc/uid/TP40011210-CH5-SW37), `atomic` "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." But Apple goes on to clarify (with an example) that "Property atomicity is not synonymous with an object’s thread safety." – Rob Nov 16 '15 at 09:47
  • are you going to respond at all OP? – luk2302 Nov 18 '15 at 11:45

2 Answers2

1

Yes

an / one atomic property is thread-safe. That is what atomicity stands for.

CAUTION

But neither are two atomic properties thread-safe in regards to each other nor are the contents of an atomic property thread-safe. (sounds a bit confusing but has be said)

That means that your are always guaranteed to be able to read a fully functional value from the property, no broken pointer, or intermediary null or whatsoever.

BUT you are not guaranteed that the values inside that atomic property are thread-safe whatsoever. That is a completely different topic.

Making all properties of a class atomic will not at all make the class itself thread-safe.

Community
  • 1
  • 1
luk2302
  • 55,258
  • 23
  • 97
  • 137
  • 1
    No, atomic does not ensure that the property is thread-safe. It only does so if the property is a fundamental data type or an immutable object. But for many objects, it does not guarantee thread safety (and if used in those cases, where further synchronization is needed, `atomic` only adds further unnecessary overhead). This is implied by your final comment, but we should not let readers infer that `atomic` ensures thread safety. – Rob Nov 15 '15 at 19:46
  • @Rob that is exactly what I am saying: the pointer is thread-safe but that has nothing to do with the object the pointer points to. – luk2302 Nov 15 '15 at 19:47
  • 1
    Agreed. But to call that "thread-safe" is a bit misleading, IMHO. Too many readers just assume "oh, I'll use `atomic` and it will be thread-safe" which is not generally true (or at least not in any meaningful sense). It only provides thread-safety in very limited situations. – Rob Nov 15 '15 at 19:50
  • @Rob okay, will clarify in a bit, am on mobile at the Moment – luk2302 Nov 15 '15 at 19:51
  • @Rob "Too many readers just assume [...]" – Then they shouldn't write multithreaded code in the first place. There's no silver bullet for thread-safety apart from writing single-threaded apps. – Tamás Zahola Nov 15 '15 at 22:06
  • 2
    @TamásZahola - That's my point. The correct answer to "does `atomic` make my code thread-safe?" is not an emphatic, "yes", but rather a far more guarded "no, it's far more complicated than that." To leave the impression that `atomic` properties result in thread-safe code is a great disservice to developers new to multi-threaded coding. – Rob Nov 16 '15 at 00:33
  • @Rob if the question were phrased that way I would have said that too. But he was asking whether atomic properties are thread-safe, which is true. The point is that two or more atomic operations generally don't add up into an atomic composite operation. To alleviate this problem we have software transactional memory ( https://en.wikipedia.org/wiki/Software_transactional_memory#Composable_operations ) but that's a whole different story... – Tamás Zahola Nov 16 '15 at 09:02
0

The property accessors are thread-safe. Basically an atomic property is equivalent to this:

- (id)atomicProperty {
    @synchronized(self) {
        return _atomicProperty;
    }
}

- (void)setAtomicProperty:(id)atomicProperty {
    @synchronized(self) {
        _atomicProperty = atomicProperty;
    }
}
Tamás Zahola
  • 9,271
  • 4
  • 34
  • 46
  • 1
    As discussed in the comments to another answer, `atomic` (or your `@synchronized` rendition) offer only a very minimal notion of thread-safety, and often, in practice, a broader level of synchronization is necessary to achieve true thread-safety. When dealing with mutable objects, accessor-level synchronization is insufficient to achieve thread-safety. – Rob Nov 15 '15 at 20:07
  • Exactly. A sequence of thread-safe method calls is _not_ thread-safe. But nonetheless, the property getters and setters are thread-safe in the sense that the underlying ivar is set atomically (hence the name atomic). – Tamás Zahola Nov 15 '15 at 22:05
  • 1
    I do not know why we got downvoted, take my upvote as compensation ;) – luk2302 Nov 23 '15 at 07:42