On May 20, 2015, at 3:41 AM, Britt Durbrow <bdurb...@rattlesnakehillsoftworks.com> wrote: > >> On May 19, 2015, at 8:37 PM, Graham Cox <graham....@bigpond.com >> <mailto:graham....@bigpond.com>> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
