[Openib-windows] RE: Reference count as a solution to the problem of an object lif e time

[Tzachi Dar]

Hi Fab,

Perhaps I'm wrong about this, but there is one difference between the two
models. 
I believe that this difference is what forces one to wait for the destroy
completion. This difference is when the number of call backs is not known to
the user. In my approach the library can play with the reference count and
make sure that it is increased even when there are more than one callback,
while on your model (one removes the reference in the callback) one can not
know when to remove the reference. A good example for this is the CM API's.
If I understand correctly, one call CM_REQ and doesn't know how many call
backs there will be. For example I have received a REP, and if I was too
busy to answer I have received a DREQ. As I understood it, the only way to
know that the last callback was sent is to wait for the completion of the
destroy of the QP.

A similar example is a timer object that works automatically, that is you
set it once and every second, you get a call back. A new callback, is
started even if the previous wasn't. In this model, when I want to stop
things, I just can't know when the last call back will happen. The only way
to solve this is to call stop on timer, wait (event, callback or whatever)
for the timer to stop and than remove my reference (I want to make this
clear there might still be others using this object!!!). 

On the model that I propose, the timer will increase the reference count
before each callback and will decrease the reference after the callback.
As a result, after I call stop on the timer, I can safely remove me
reference, and I DON'T HAVE TO WAIT. 

Is there someway to solve this problem in your model?

Thanks
Tzachi

>-----Original Message-----
>From: Fab Tillier [mailto:ftillier at silverstorm.com]
>Sent: Monday, September 19, 2005 7:35 AM
>To: 'Tzachi Dar'; openib-windows at openib.org
>Subject: RE: Reference count as a solution to the problem of an object life
>time
>
>> From: Tzachi Dar [mailto:tzachid at mellanox.co.il]
>> Sent: Sunday, September 18, 2005 12:38 PM
>>
>> Hi Fab,
>>
>> It seems that the only place in which I'm missing you is why there is a
>need
>> for a "destroy complete" call-back. According to the method that I
>mention,
>> there is no need for that I just call destroy and forget about the
>object. I
>> haven't yet figured why the destroy call back is needed on your approach.
>
>In your model, you define a standard interface for taking and releasing
>references on objects.  When creating an object that invokes callbacks (B
>in
>this example), the client passes in such an interface representing its
>context
>object (A in this example).  B is returned with a reference held on behalf
>of
>the caller.  Before being returned, B takes a reference on A and holds it
>as
>long as it can have callbacks outstanding.  Once A destroys B, A can't go
>away
>until B releases the reference on it, which it can only do once all
>callbacks
>are delivered.  In this case, you don't need to specify a destroy callback
>at
>destruction time since the dereference handler for A is equivalent.  You've
>just
>specified the equivalent of the destroy callback at creation time.
>
>In the current model, B doesn't take an interface to A, it takes an opaque
>pointer as context, but has no knowledge of how to do anything with that
>context.  When A decides to destroy B, it provides a destroy callback so
>that B
>can properly synchronize callback delivery with destruction.  What A does
>in the
>destroy callback is irrelevant to B - it just needs to do whatever is
>appropriate.  When B is done being destroyed, it invokes A's destroy
>callback.
>At creation time, A would take a reference on itself on behalf of B - this
>eliminates the need to provide a call to take a reference on A internally
>to B.
>
>The destroy callback serves as a final notification, from which the user
>typically releases a reference on its internal context and performs any
>necessary cleanup.  Think of the destroy callback as a deref for the
>context
>provided when the object was created.
>
>There's a reason the destroy callback and deref_al_obj have similar
>prototypes -
>it is to allow a user to use an al_obj_t pointer as their context, and use
>deref_al_obj as their destroy callback.  This is very similar to your
>proposed
>model, except that in the IBAL model the deref() handler is provided when
>the
>object is being destroyed rather than when it is being created.
>
>Does that make any more sense?
>
>I don't know if it's necessary/valuable to have the addref() function
>passed
>into an object.  So I think the difference between the models comes down to
>passing the deref handler at creation time or destruction time, which seems
>like
>a pretty minor difference.
>
>Whether a user waits for the deref/destroy callback or not is
>implementation
>specific - neither of our methods forces any kind of synchronous or
>asynchronous
>policy on our clients.
>
>I don't know if forcing an object model into the API makes sense - that is,
>the
>notion that all clients that expect callbacks must provide an interface to
>their
>context that we define, as well as forcing all objects created by various
>parts
>of the stack to expose the same general interface.  I would say I'm on the
>fence
>about this, leaning towards simplicity (the current model) over flexibility
>(the
>unified object model).
>
>- Fab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20050919/c1383e4f/attachment.html>