[Openib-windows] RE: Reference count as a solution to the pro blemof an object life time

[Fabian Tillier]

On 9/21/05, Tzachi Dar <tzachid at mellanox.co.il> wrote:
>
>
> 1) This seems error prone to me.  If you no longer want an object and
> decrement its reference count, you could very well destroy the associated
> context.
>
> This is exactly the point: you want an object keep a pointer to it and have
> a reference, you don't want an object, remove the reference and get rid of
> the pointer.

This adds complexity to all object implementation in that they must
now check before calling each callback if the object is in a valid
state, and if the client context is still valid.

In the existing model, since the reference to the context can only be
safely decremented from the destroy callback, an object doesn't have
to perform any checks when invoking a callback - the fact that a
callback needs to be invoked means that the object is valid, and if
the object is valid, so it the user's context.  It is a programming
error to free a context while an object can still reference it.

As a user of a QP, you take a reference on your context on behalf of
the QP.  As long as the QP exists, you are not at liberty to release
this reference - only the QP's destroy callback can do this. 
Releasing the QP's reference on the context outside of the destroy
callback is akin to dereferencing your object without taking a
reference first - you're in effect releasing someone else's reference,
which I think we all agree is a programming and logic error.

The current model is quite simple: While an object that can invoke
callbacks exists, it can invoke callbacks.  The destroy callback is
the last callback an object will ever invoke, and serves as indication
that no further callbacks will be invoked and that the user can free
its context structure.  As I have said many times, the destroy
callback is the *only* place that a user can dereference their context
from.

>
> > Getting a callback after this is likely to crash.
>
> No way, the one who is calling the callback should be having a reference,
> other wise he can't make the call.

In the existing model, the user guarantees that their context will be
valid until the object is fully destroyed.  This is independent of
whether the user specifies a destroy callback.  The destroy callback
is just there as a notification that the object is destroyed and the
user is free to do with their context whatever they please.

> > This model seems to increase the complexity for a ULP.  How can a ULP
> unload?
>
> This is indeed a point that should be solved and I have a solution for it, I
> just don't want to make things too complicated. Believe me that there is a
> solution that doesn't require a complete change of the model. (We can talk
> about it in a different thread if anyone wants).

I don't think we need to discuss ULP unload issues until we determine
that there's a need to change the existing object model.  I don't see
any need or advantage to your model over the existing one and would
rather focus my time and energy solving real problems.

How does the existing model prevent you from implementing robust
reference counting?

>  How can it signal the CM that it will no longer be around to receive a
> callback?
>
> An app that allocates an object can't simply forget about it.  Using this
> method, the creator of the object will never know if a callback will occur
> for some past created object, so can never cleanup anything associated with
> the object.
>
> The creator of the object doesn't have to know when the object is destroyed;
> it just has to know that it will be destroyed. The object will clean all
> it's resources once the object is cleared from memory.

Use the destroy callback to release the reference you took for the
object when you created it, and you get the exact same behavior.

The only thing that your model lets users do is pass objects around. 
However, unless you can change the callbacks at runtime (which in
itself is another change to the object model), you can't pass callback
driven objects around.  I don't see the need to support passing
objects around - who wants it, and why can't the existing model be
used?

So far this discussion has focused on possible changes to a working
API model just for the sake of change.  No concrete reason has been
presented for making the change.  In light of this, I'd like to close
this topic of discussion and move on to solving real problems in the
existing design.

- Fab