Cocoa atomic properties and autorelease

Question

If I have an an atomic property in MyClass:

@property (readwrite, strong) NSMutableArray *atomicArray;

And a thread calls something like:

NSMutableArray* t = [myClassObject atomicArray];

Where is it documented that the object I get back is retained/autoreleased so that another thread can't call: [myClassObject setAtomicArray:otherArray] and eliminate the object out from under me?

Another question mentioned this is true but without reference to any documentation from Apple.

Atomic properties vs thread-safe in Objective-C

score 2 · Answer 1 · edited Jul 17 '22 at 16:07

2

See The Objective-C Programming Language, Property Declaration Attributes, Atomicity:

If you specify strong, copy, or retain and do not specify nonatomic, then in a reference-counted environment, a synthesized get accessor for an object property uses a lock and retains and autoreleases the returned value—the implementation will be similar to the following:
[_internal lock]; // lock using an object-level lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;
If you specify nonatomic, a synthesized accessor for an object property simply returns the value directly.

edited Jul 17 '22 at 16:07

Rob

415,655
72
787
1,044

answered Jul 16 '22 at 20:47

Willeke

14,578
4
19
47

How does this work in a non-ARC environment with atomic properties? – Trygve Jul 16 '22 at 21:50
1

@trygve is the non-ARC environment a reference-counted environment? – Willeke Jul 16 '22 at 22:19
Yes. I was reading "reference-counted environment" as ARC when that is not necessarily true. Thanks. – Trygve Jul 16 '22 at 22:49

score 1 · Answer 2 · answered Jul 16 '22 at 17:10

Assuming you are using ARC, the reference obtained in t is a strong one to the object that existed at the time you retrieved it. If some other thread replaces the object, t would still reference the original object, and that object would stick around until t goes out of scope.

However t being a mutable array, some other thread could get its own reference and modify the mutable array itself by adding and removing objects. Those changes would be visible to your t, because it is the same object.

That is important, because if you try to iterate over the array while some other thread modifies it, you may encounter all kinds of unexpected results. Depending on your Xcode version it might produces warnings during compile and/or runtime to help identify those scenarios. One pattern to avoid the array changing from under you is to create an immutable copy, like NSArray *immutableT=[t copy]. This produces a shallow copy of the array that is immune to changes to the original mutable array, so you can safely iterate over immutableT.

Without ARC, is an atomic property getter guaranteed to so something like `[[object retain] autorelease]` so that the caller owns the object, thus preventing the object from disappearing without warning? — Trygve, Jul 16 '22 at 19:52

score 1 · Answer 3 · answered Jul 19 '22 at 06:47

1

This is a helpful hint, but can you try using Memory Graph Debugger feature of Xcode. Working on strong attributes with multi-threading is always a tedious task.

Memory graph debugger is an excellent tool to find out retain count, who is holding a strong reference of an object, etc.. It helps a lot if you play around with it.

answered Jul 19 '22 at 06:47

sanjirambo

53
6

Does it work with manual reference counting (autorelease)? – Willeke Jul 19 '22 at 11:22
@Willeke Yes. It does!!! – sanjirambo Jul 20 '22 at 10:15

Cocoa atomic properties and autorelease

3 Answers3