Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Charles Srstka <email@hidden>
- Date: Wed, 20 May 2015 11:09:51 -0500
On May 20, 2015, at 3:41 AM, Britt Durbrow <email@hidden> wrote:
>
>> On May 19, 2015, at 8:37 PM, Graham Cox <email@hidden <mailto:email@hidden>> wrote:
>>
>> I think what the OP says he wants is that the cache can only release when it knows nobody else has a reference to an object as well, hence the temptation to peek at the retain count. In other words it must be the “last owner”, for some reason.
>
> Yes, exactly: the reason being that of maintaining graph coherency.
>
> Suppose we have these objects in play:
>
> The object pool controller, call it OPC.
> A view controller, call it VC1.
> Another view controller, call it VC2.
> A document model object in the pool controlled by OPC, call it DMO1 (and lets say it’s got a UUID of 12345, cuz’ ya know, that’s the combination on my luggage ;-)
>
> The view controller VC1 has a strong reference to DMO1
>
> A memory pressure event occurs, and OPC decides to evict DMO1, but it doesn’t immediately go away, because VC1 is holding on to it.
>
> VC2 comes along and wants to get at the object with UUID 12345 (in order to execute [someObject stealAllTheAir], lets say).
> Sooo… OPC loads the data for UUID 12345 from file storage, alloc’s a new object (call it DMO2), sets it’s parameters (including assigning the UUID to it), puts it in the in-RAM object pool, and returns the new object as being the object for UUID12345. Note that this can often happen as a result of a fault firing, so VC2 didn’t even know it was asking for UUID 12345, just that it was messaging a pointer to some object.
>
> So, at this point, in RAM there is: OPC (who knows DMO2 as UUID 12345), VC1 (who knows DMO1 as 12345), VC2 (who knows DMO2 as 12345), DMO1 (who thinks it is UUID 12345), and DMO2 (who also thinks it is UUID 12345).
>
> And now VC1 is writing to DMO1, thinking it’s updating UUID 12345, at the same time as VC2 is doing the same thing to DMO2, also thinking it’s talking to UUID 12345.
>
> BOOM, loss of graph coherency.
The flaw in this example is that VC1 continuing to use DMO1 even after it has told OPC that it’s done with it is a programmer error. All usage of an object that conforms to NSDiscardableContent needs to be between calls to -beginContentAccess and -endContentAccess, and you can enforce this by causing the object to throw an exception if any of its methods are called without -beginContentAccess having been called first (this is, incidentally, what the documentation for NSDiscardableContent recommends). In the case where the object has already been discarded and replaced by DMO2, -beginContentAccess returns NO, and VC1 knows that it needs to ask OPC for a new object (and again, if it tries to use the object anyway, you throw an exception).
Charles
_______________________________________________
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