[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?
- Re: deferred deallocation of local objects, (continued)
Re: deferred deallocation of local objects, Derek Zhou, 2003/10/16
Re: deferred deallocation of local objects, Derek Zhou, 2003/10/18