Is Dipose( ) a contractual obligation, if you provide one?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Kevin Frey - 10 May 2006 05:24 GMT

If you have a class that manages a resource (or something similar such as an
unmanaged pointer), and you implement a Dispose( ) method, are you mandating
to the users of your assembly that they *must* use this method to clean up
(or endure leaks or whatever)? Does this become one of their contractual
obligations in using this assembly?

Are are you simply saying to developers: "Because this class manages a
resource, Dispose( ) gives you the opportunity to force this object to
relinquish its resources at an explicit point." In other words, if the user
*does not* call Dispose( ), then the finaliser should still (at some point)
take care of cleaning up the resources, and it is *legal* for a program to
be written this way?

The reason I ask is that we have a quite complicated framework of Managed
objects (actually written in Managed C++) that control unmanaged resources
(native C++ objects). The key complication is that there are dependencies
amongst the unmanaged resources.

For example, a UEntity unmanaged object requires a USession unmanaged object
in order to communicate with an application server over TCP/IP,. The UEntity
unmanaged object is controlled by a managed Entity object, and the USession
object is controlled by a managed Session object. Naturally enough when
Entity finalises, it will release its corresponding resources, with same
said for the Session object.

The nett result is that, without convoluted handling code, it is entirely
possible for Session to finalise *before* Entity. The finaliser for Session
would in turn clean up USession.

The finaliser for Entity is now stuck between a rock and a hard place. It
needs USession to ensure it can communicate something back to the
application server, yet USession has been destroyed.

Has anyone come across this kind of situation before? It would seem to me
that the only practical way of ensuring that the dependencies are retained
is to use reference-counted pointers for the unmanaged resources.

That way Session holds 1 reference to the USession object, and Entity holds
1 reference. USession only "self-destructs" if the reference count drops to
zero, so a finalise of Session ahead of USession would reduce the reference
count but not result in object destruction of USession because Entity is
still holding a reference.

If anyone has solved this in any other different/lateral/imaginative way I'd
be pleased to hear about it.

Thanks

Kevin

Reply to this Message

Carl Daniel [VC++ MVP] - 10 May 2006 06:16 GMT

> If you have a class that manages a resource (or something similar
> such as an unmanaged pointer), and you implement a Dispose( ) method,
> are you mandating to the users of your assembly that they *must* use
> this method to clean up (or endure leaks or whatever)? Does this
> become one of their contractual obligations in using this assembly?

You're at least saying "it'd be a really good idea for you to call Dispose
on this object when you're done with it, or something expensive is likely to
be wasted."

> Are are you simply saying to developers: "Because this class manages a
> resource, Dispose( ) gives you the opportunity to force this object to
[quoted text clipped - 3 lines]
> point) take care of cleaning up the resources, and it is *legal* for
> a program to be written this way?

Yes it's legal (if unadvisable), and the finalizer should take care. The
preferred pattern for implenting IDisposable is this (C# syntax, sorry):

class C : IDisposable
{
private void IDisposable.Dispose()
{
Dispose(true);
}

~C()
{
Dispose(false);
}

protected virtual void Dispose(bool disposing)
{
if (disposing)
{
// release managed resources
GC.SuppressFinalize(this);
}

// release unmanaged resources
}
}

> The reason I ask is that we have a quite complicated framework of
> Managed objects (actually written in Managed C++) that control
[quoted text clipped - 15 lines]
> place. It needs USession to ensure it can communicate something back
> to the application server, yet USession has been destroyed.

It's important that the finalizer for Entity not try to do anything other
than clean up resources. That probably includes attempting to communicate.
If you have a "close" protocol, let Dispose() initiate that, but just drop
the connection if you get to the finalizer.

> Has anyone come across this kind of situation before? It would seem
> to me that the only practical way of ensuring that the dependencies
[quoted text clipped - 8 lines]
> If anyone has solved this in any other different/lateral/imaginative
> way I'd be pleased to hear about it.

You may indeed need to use reference counting on the unmanaged objects if
your UEntity has a direct relationship with a USession that's managed by a
different object, just as you would in a pure unmanaged case if a single
object (USession) has two "owners".

-cd

Reply to this Message

Rate this thread:

Is Dipose( ) a contractual obligation, if you provide one?

Free Magazines