Re: Newbie question: how to release an object that has been autoreleased
Re: Newbie question: how to release an object that has been autoreleased
- Subject: Re: Newbie question: how to release an object that has been autoreleased
- From: James Bucanek <email@hidden>
- Date: Wed, 22 Sep 2004 11:16:50 -0700
M. Uli Kusterer wrote on Wednesday, September 22, 2004:
>At 8:04 Uhr -0700 22.09.2004, James Bucanek wrote:
>>In this particular case, these buffers are being created (from the
>>Pool object) and handed out to several threads which fill them with
>>data.
>
> Aaaahh! Danger, Will Robinson!
I already got that memo. ;)
> Autorelease pools are per-thread. If you autorelease an object and
>hand it off to another thread, the original thread may dispose of it
>while the new one is still working on it. So, in this case your
>second thread *must* retain it.
I understand all of that, and they do. The situation is this:
BufferPool lives in thread "bp_thread". BufferPool is a factory object which creates Buffer objects in response to [BufferPool bufferFromPool].
As per the Cocoa guidelines, BufferPool was doing this via 'return [[[Buffer alloc] initWithSomeMagic] autorelease]' so the returned object was autoreleased (in bp_thread's pool).
The Buffer is then immediately placed in a queue of "ready to use" buffers.
Clients (running in other threads) then pull Buffers out of the queue, work on them, then push them onto an "all done" queue.
The consumer of the "all done" queue is the orignal bp_thread, which assembles the Buffers and write them to disk. At this point bp_thread would like to immediatley release the Buffer so it can be recycled.
The problem was that because BufferPool autoreleased the Buffer in the first place it can't be released immediately.
> I know that you could theoretically have the first thread in a loop
>which doesn't exit until the second thread has finished, but to rely
>on that is very fragile.
Nothing that fragile here. Clients retain each Buffer while working on it. Ditto for the incoming and outgoing queues. Note that the retains are carefully overlapped (i.e. the client retains the Buffer before removing from the queue), so the Buffer is never left in a state where it could be destroyed by bp_thread's autorelease pool until the Buffer is returned to bp_thread.
> So, just do as the designers of Cocoa's memory management scheme
>intended and retain your object in the second thread. Then the first
>one can release it whenever it wants and nobody has to wait for the
>other.
Normally, that would be true. But in my case, these objects make a complete round-trip; They are created and destroyed by the factory thread.
Given that symmetry, I'm going to change the factory to simply NOT autorelease the object. It will keep the object retained until it comes back, at which time it can be released immediately.
My only problem is all the special cases where there is an error and the Buffer is not completely processed for some reason. I'll have to take care of sending an extra release to the objects that dont' make it back to the original thread, rather being able to rely on the autorelease pool to do it for me. *sigh*
--
James Bucanek <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden