Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Graham Cox <email@hidden>
- Date: Wed, 20 May 2015 16:35:47 +1000
> On 20 May 2015, at 2:17 pm, Quincey Morris <email@hidden> wrote:
>
> My answer on this to Britt is that this is unknowable in general. *That* (or so I claim) is why it’s not safe to reason about retain counts. If Britt could be said to be wrong about anything, I’d say it’s this, the idea that “nobody else has a reference” is a meaningful concept. For all practical purposes it isn’t**.
>
> — It’s unknowable in general. Various parts of the system frameworks may have a need to reference your object for some reason that you don’t know and don’t care about. One sort of trivial example would be when zombies are enabled. In that case, there’s a strong reference to every object ever created. A more practical (though hypothetical) example might be if your object is retained by a NSInvocation that’s already been used for some purpose, but is itself cached somewhere in the frameworks and won’t be purged until some future time you can’t control.
>
> — The state of the memory management system may not be internally consistent at every single moment in time. For example, an object that’s in the process of being freed may for a short while still have an actual retain count of 1 even though there are no strong references to it anywhere. (It’s not the same thing really, but I seem to recall that due to serial nil’ing of weak references in ARC there can be short timing windows during dealloc where a weak reference is still non-nil but the object it refers to is gone. The runtime prevents you from using it, but it still has some very weird consequences. I think this came up on cocoa-dev about a year ago.)
>
> — There may be implementation details that you can’t take into account. What if (hypothetically) there were two different retain counters for every object — say a Cocoa retain count and a CF retain count? What could you then conclude from [someObject retainCount] alone? Nothing at all, really.
>
>
> ** Nor does Britt’s app need it to be. All that’s necessary is that old objects be inaccessible. The existing code ensures that.
>
I entirely agree with your reasoning, though not your (earlier) conclusion, which was:
>> just pointing you at NSDiscardableContent for a second, that has a “pseudo-retain count” type of mechanism
>
> I believe this is functionally identical to incrementing the actual retain counts, so it’d be a matter of personal preference which to use.
>
I think the problem is that Britt is conflating two semantically distinct things: whether the object exists, and whether the object is “in use”. S/he is attempting to determine that the object is not “in use” while it still exists by peeking at retainCount to see if it’s 1.
As we both agree that for all sorts of reasons you can’t reason about the retain count, that leaves the need to clearly figure out the in use/not in use state by some other means, and that is what I suggest NSDiscardableContent (or similar) is for. In fact Apple have designed that for exactly the case presented here - the caching of objects in such a way that they can be discarded when they’re not in use, because NSCache works with NSDiscardableContent (though not exclusively).
It certainly requires extra work for client code that uses these objects, because the existing retain/release methods are not enough to signal “in use”, so some other way to signal it is needed, together (probably) with some enforcement that accessing content without flagging that you’re going to access it throws an exception, etc. This catches the case where something is retaining the object, thus keeping it alive, and yet it’s not “in use”. The cache should be free to discard it at that time, but if it does so, it will also need to do something to the object’s state such that if code that is retaining it tries to put it back into use, that is disallowed (assuming that this is a rule of Britt’s design, which it sounds like).
So there are three states:
exists
in use
discarded
in use and discarded must be mutually exclusive, and enforced to be so. An object that has been discarded can still exist, though it also can be purged from the cache and will dealloc when all other references to it dies, but while it still exists and discarded is true, it can no longer be used. Once it’s discarded, then it’s effectively dead, to all intents and purposes, even if something retains it. The cache is no longer aware of it, and any client can no longer use it. Sounds like a workable approach to me without conflating any of this with memory management.
—Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden