[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deferred deallocation of local objects

From: Richard Frith-Macdonald
Subject: Re: deferred deallocation of local objects
Date: Mon, 20 Oct 2003 08:27:13 +0100

On Sunday, October 19, 2003, at 06:35 AM, Richard Frith-Macdonald wrote:

On Saturday, October 18, 2003, at 08:20 PM, Derek Zhou wrote:

However, there is another error condition possible between A and B
without involving C:

A vends O to B (oneway void) producing proxy P in B
B uses P and releases it, sending release message to A
A vends O to B again .... before receiving the release message.
A receives the release message and destroys local proxy releasing O
B receives reference to O from A and tries to use it ...

Your solution would fix the original three-way problem, but not this
two way problem.
Well, if A vends the object again, the retaincount at A should plus one; then it takes 2 release messages from B to dealloc the object. IMHO, tracking
message sequence number in retain/release is overkill.

At the moment, the local object is retained only once (when initially vended) and the retain count is not increased if it is vended again. Similarly, retains and releases of the proxy in B are local to B until the proxy is actually
deallocated ... at which time a release message is sent back to A.
Working with multiple retains of the local object (once each time it is vended) and multiple releases from the other end, would need quite a bit of extra work.

The connection in A would need to track the number of times the object had been retained so that, on invalidation of the connection, it could release the object a corresponding number of times. The connection in B would need to track the number of times it had received the object, and send that number of
release messages back when it no longer needs it.

This might easily be more work than watching the packet sequence numbers.
On the other hand, it looks a bit more intuitive.

Having spent some thinking about this, I think we might do this reference
counting fairly cleanly (ie less work than matching sequence numbers).
We can't just use the retain count, because other objects may retain/release
proxies and these retain/release operations won't necessarily equate to
messages we should send between processes/threads.

However, if we add a counter ivar to the NSDistantObject class, we can
increment that counter whenever we send a local proxy to the remote end,
and in the remote proxy whenever the message is received.  Both these
operations involve lock-protected lookup of the NSDistantObjects in the
connection, so if we manipulated the counter in these protected regions
of code, things should be thread-safe.

This counter should therefore track (in both processes) the number of times
the original object was vended.

When the proxy in the remote process is deallocated, it would send back as
many releases as it has stored in the counter (we may need to change the
release packet to contain a count). This would be done at the point when the
proxy is removed from the connection ... again a lock protected region.

When the releases are received, the counter in the local proxy would be
decremented by the number of releases and, if it goes to zero, the local
proxy would be invalidated and removed from the connection, releasing
the original object to which it refers. We would need to use the connection
proxy lock to protect this operation.

Does this seem OK?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]