Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Dave <email@hidden>
- Date: Wed, 20 May 2015 13:00:09 +0100
I’ve been read this thread with interest, I think you are over-complicating things, unless I missed something.
Look at the following pseudo code:
// Create a New Payload Object
LTWPayloadItem* myPayloadItem; //An object that contains references to other objects
NSString* myItemID;
myItemID = @“ID-001”;
myPayloadItem = [[LTWPayloadItem alloc] initWithSomeParameters:xxxxxx];
[self.pPayloadDictionary setObject: myPayloadItem forKey: myItemID];
[myPayloadItem release];
// At this point, myPayloadItem has a retain count of 1
So if you remove it from the dictionary (which is what you want to do under when under memory pressure):
[self.pPayloadDictionary removeObjectForKey: myItemID];
It will be dealloc’ed.
If another part of the application wants to access Item “ID-001”, then if they always access it like this:
myPayloadObject = [self.pPayloadDictionary ObjectForKey: @“ID-001"];
[myPayloadObject retain]; //Retain count of 2
Now if Item “ID-001” get removed from the dictionary, it will not be dealloc’ed, but it will be removed from the dictionary.
When the code has finished accessing the item “ID-001”, it executes:
[myPayloadObject release]; //Retain count of 1
Now if Item “ID-001” get removed from the dictionary, it will also be dealloc’ed.
Isn’t this what you want to achieve?
Of course this would be implemented as a Global Manager Class which is called from other parts of the application, something like this:
-(void) addItemID:(NSString*) theID withPayloadItem:(LTWPayloadItem*) thePayloadItem
{
@synchronized (self.pPayloadDictionary)
{
[self.pPayloadDictionary setObject: thePayloadItem forKey:theID];
}
}
-(void) removeItemID:(NSString*) theID
{
@synchronized (self.pPayloadDictionary)
{
[self.pPayloadDictionary removeObjectForKey:theID];
}
}
-(void) addItemID:(NSString* theID withPayloadItem:(LTWPayloadItem*) thePayloadItem
{
@synchronized (self.pPayloadDictionary)
{
[self.pPayloadDictionary setObject: thePayloadItem forKey:theID];
}
}
-(LTWPayloadItem*) newAccessWithID:(NSString* theID
{
LTWPayloadItem* myPayloadItem;
@synchronized (self.pPayloadDictionary)
{
myPayloadItem = [self.pPayloadDictionary objectForKey:theID];
}
[myPayloadItem retain];
return myPayloadItem;
}
-(void) releaseAccessWithPayload:(LTWPayloadItem*) thePayloadItem
{
[thePayloadItem release];
}
All the Best
Dave
> On 18 May 2015, at 01:47, Britt Durbrow <email@hidden> wrote:
>
> Ughh… I find myself in a bit of a quandary:
>
> I have a pool of disk-backed (well, flash-backed on iOS) objects that have an arbitrary graph structure. These are managed by a central object pool. The object pool is supposed to cache these in memory (creating them is somewhat non-trivial), and hold onto ones that it’s been told to even if there are no other objects that currently have an active pointer to them outside of the pool’s object graph (consequently, just using weak links won’t work for my problem).
>
> In order to respond to iOS memory pressure warnings, I need to have the object pool de-construct and release any graph segments that are not currently being used outside of the object pool. However, this needs to happen only during a memory pressure event, and not otherwise.
>
> The only thing I’ve been able to come up with so far is somehow tracking the retain count state of the objects in the object pool, and when a memory pressure event occurs having the object pool find all the objects that are only in use in the graph and held by itself, and release them. Once all the otherwise unused objects have been converted via an isa swizzle to faults (and thusly no longer contain retain cycles), the faulted objects that are candidates for release should have a retain count of 1… at which point I can have the pool remove them from it’s main NSMutableDictionary (which will now cause them to be deallocated).
>
> This, however, is kinda ugly… and known to be prone to pitfalls... but is there any better way?
>
> Note that I don’t want to just use CoreData. Also, I did think of having the objects in the graph that are supposed to be held on to be held in a strong container, and the objects not currently being held on to in a weak container, but that doesn’t work because then the objects in the weak container will get purged when immediately, not just under a memory pressure event.
>
>
> So what I’m looking at now is creating an intermediate base class for all of these objects, that is compiled with ARC turned off, and provides access to retainCount. Yes, I know that it doesn’t reflect any autoreleases that have occurred on the object. This is OK as far as I know - for this specific use, if something has an outstanding autorelease on an object, it’s probably OK to keep it around, as long as enough of the cached objects get purged to satisfy the memory pressure event. Also, this object pool is not guaranteed to be thread-safe so I don’t think that the potential race conditions of retain/release/autorelease/retainCount interaction will come into play.
>
>
> Any ideas? Comments? Rotten tomatoes? :-)
> _______________________________________________
>
> 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
_______________________________________________
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