Dispose pattern

[Thore Berntsen]

I'm trying to understand the IDisposable pattern. In the sample on MSDN they
have added a destructor/finalizer like this:

~MyResource()
{
Dispose(false);
}

Calling Dispose(false) will only dispose non managed resources. If I
implement IDisposable only to dispose managed resources isn't this finalizer
unecessary then? Wouldn't the finalizer just at an extra burdon on the GC?

The MSDN sample is found here:
http://msdn2.microsoft.com/en-us/lib...isposable.aspx

Thore Berntsen

[Jesse Houwing]

* Thore Berntsen wrote, On 28-5-2007 12:03:

I'm trying to understand the IDisposable pattern. In the sample on MSDN they
have added a destructor/finalizer like this:

~MyResource()
{
Dispose(false);
}

Calling Dispose(false) will only dispose non managed resources. If I
implement IDisposable only to dispose managed resources isn't this finalizer
unecessary then? Wouldn't the finalizer just at an extra burdon on the GC?

The MSDN sample is found here:
http://msdn2.microsoft.com/en-us/lib...isposable.aspx

Thore Berntsen

That is correct. But it is best to implement your Dispose to call a
protected virtual Dispose(bool) method regardless of the fact whether
have a finalizer. Should you need one later you won't have to change much.

Jesse

[Lee Alexander]

Thore,

Your quite correct, there is certainly an added overhead using a finalizer,
so if you don't need it, don't use it,. Finalizable objects usually get
promoted to a higher generation and as a result stay in memory longer, as
the GC spends more of it's time in the lower generations. This is why
GC.SupressFinalize is so important, it stops the extra work being done if
the object has already been disposed. Also the finalizer is called in a
seperate thread so you have to take that into consideration if you have any
shared resources.

Regarding what Jesse said, I'm in the less code is better camp, so if you
don't use a finalizer I wouldn't bother with the Dispose( bool disposing )
method.
Regards

Lee Alexander
www.feedghost.com
An RSS Reader for Vista & XP
Synchronize, search, tag and share.

"Thore Berntsen" <someone@microsoft,comwrote in message
news:up**************@TK2MSFTNGP03.phx.gbl...

I'm trying to understand the IDisposable pattern. In the sample on MSDN
they have added a destructor/finalizer like this:

~MyResource()
{
Dispose(false);
}

Calling Dispose(false) will only dispose non managed resources. If I
implement IDisposable only to dispose managed resources isn't this
finalizer unecessary then? Wouldn't the finalizer just at an extra burdon
on the GC?

The MSDN sample is found here:
http://msdn2.microsoft.com/en-us/lib...isposable.aspx

Thore Berntsen

[Thore Berntsen]

Thank you both for confirming this. I wil remove my unecessary finalizers
rigth away. Actually I'm working on a Compact Framework application. Althoug
the GC is a bit different here I still think I should use the pattern from
the full framework.
"Lee Alexander" <lee@feedghost_dot_comwrote in message
news:O1**************@TK2MSFTNGP05.phx.gbl...

Thore,

Your quite correct, there is certainly an added overhead using a
finalizer, so if you don't need it, don't use it,. Finalizable objects
usually get promoted to a higher generation and as a result stay in memory
longer, as the GC spends more of it's time in the lower generations. This
is why GC.SupressFinalize is so important, it stops the extra work being
done if the object has already been disposed. Also the finalizer is called
in a seperate thread so you have to take that into consideration if you
have any shared resources.

Regarding what Jesse said, I'm in the less code is better camp, so if you
don't use a finalizer I wouldn't bother with the Dispose( bool disposing )
method.
Regards

Lee Alexander
www.feedghost.com
An RSS Reader for Vista & XP
Synchronize, search, tag and share.

"Thore Berntsen" <someone@microsoft,comwrote in message
news:up**************@TK2MSFTNGP03.phx.gbl...

>I'm trying to understand the IDisposable pattern. In the sample on MSDN
they have added a destructor/finalizer like this:

~MyResource()
{
Dispose(false);
}

Calling Dispose(false) will only dispose non managed resources. If I
implement IDisposable only to dispose managed resources isn't this
finalizer unecessary then? Wouldn't the finalizer just at an extra burdon
on the GC?

The MSDN sample is found here:
http://msdn2.microsoft.com/en-us/lib...isposable.aspx

Thore Berntsen

[Jon Skeet [C# MVP]]

Jesse Houwing <je***********@nospam-sogeti.nlwrote:

That is correct. But it is best to implement your Dispose to call a
protected virtual Dispose(bool) method regardless of the fact whether
have a finalizer. Should you need one later you won't have to change much.

I disagree - I *very* rarely need a finalizer, which makes the whole
Dispose(bool) extra method a bit pointless. Why add an extra level of
indirection *just in case* you need it - you won't have to change much
anyway even without the extra level of indirection.

The only reason I can think of to add this complexity without an
immediate need is if you're creating a class which others may derive
from. At that point you're in a different ballgame, as changing things
later becomes a versioning issue.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Lee Alexander <lee@feedghost_dot_comwrote:

Your quite correct, there is certainly an added overhead using a finalizer,
so if you don't need it, don't use it,. Finalizable objects usually get
promoted to a higher generation and as a result stay in memory longer, as
the GC spends more of it's time in the lower generations. This is why
GC.SupressFinalize is so important, it stops the extra work being done if
the object has already been disposed. Also the finalizer is called in a
seperate thread so you have to take that into consideration if you have any
shared resources.

Note that even with SuppressFinalize there's an overhead in having a
finalizer to start with, in that the object is initially added to the
finalizer queue and then removed when SuppressFinalize is called. You'd
need to be creating an awful lot of objects to make this significant,
but it's still a hit.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jesse Houwing]

* Jon Skeet [C# MVP] wrote, On 28-5-2007 16:39:

Jesse Houwing <je***********@nospam-sogeti.nlwrote:

>That is correct. But it is best to implement your Dispose to call a
protected virtual Dispose(bool) method regardless of the fact whether
have a finalizer. Should you need one later you won't have to change much.

I disagree - I *very* rarely need a finalizer, which makes the whole
Dispose(bool) extra method a bit pointless. Why add an extra level of
indirection *just in case* you need it - you won't have to change much
anyway even without the extra level of indirection.

The only reason I can think of to add this complexity without an
immediate need is if you're creating a class which others may derive
from. At that point you're in a different ballgame, as changing things
later becomes a versioning issue.

I'm usually building classes others need to derive from, or at least
make them so they can be inherited from in the near future. That's why I
usually do it from the start. It's also easier to understand for less
experienced programmers if you do it the same way under all circumstances..

Jesse

[Jon Skeet [C# MVP]]

Jesse Houwing <je***********@nospam-sogeti.nlwrote:

The only reason I can think of to add this complexity without an
immediate need is if you're creating a class which others may derive
from. At that point you're in a different ballgame, as changing things
later becomes a versioning issue.

I'm usually building classes others need to derive from, or at least
make them so they can be inherited from in the near future.

I rarely try to design for inheritance - it's a very restrictive thing
to do, IME.

That's why I
usually do it from the start. It's also easier to understand for less
experienced programmers if you do it the same way under all circumstances..

And those less experienced programmers are likely to be *directly*
holding unmanaged resources (the only time you should usually have a
finalizer)? Scary.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jesse Houwing]

<snip>

And those less experienced programmers are likely to be *directly*
holding unmanaged resources (the only time you should usually have a
finalizer)? Scary.

It is scary. The biggest problem is that they most of the time only
realize they are when they run Code Analysis. Which gives them a hint.
And it's usually during maintenance work after code ownership has
transferred to some other party.

Jesse

[Ben Voigt]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Jesse Houwing <je***********@nospam-sogeti.nlwrote:

>That is correct. But it is best to implement your Dispose to call a
protected virtual Dispose(bool) method regardless of the fact whether
have a finalizer. Should you need one later you won't have to change
much.

I disagree - I *very* rarely need a finalizer, which makes the whole
Dispose(bool) extra method a bit pointless. Why add an extra level of
indirection *just in case* you need it - you won't have to change much
anyway even without the extra level of indirection.

The only reason I can think of to add this complexity without an
immediate need is if you're creating a class which others may derive
from. At that point you're in a different ballgame, as changing things
later becomes a versioning issue.

Still a non-issue. The derived class needs a finalizer if it holds
unmanaged resources, and it is no more difficult for the programmer to
implement the finalizer than to override your Dispose(bool) class. The
finalizer should be first introduced by the class holding unmanaged
resources, not some base class.

[Ben Voigt]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Lee Alexander <lee@feedghost_dot_comwrote:

>Your quite correct, there is certainly an added overhead using a
finalizer,
so if you don't need it, don't use it,. Finalizable objects usually get
promoted to a higher generation and as a result stay in memory longer, as
the GC spends more of it's time in the lower generations. This is why
GC.SupressFinalize is so important, it stops the extra work being done if
the object has already been disposed. Also the finalizer is called in a
seperate thread so you have to take that into consideration if you have
any
shared resources.

Note that even with SuppressFinalize there's an overhead in having a
finalizer to start with, in that the object is initially added to the
finalizer queue and then removed when SuppressFinalize is called. You'd
need to be creating an awful lot of objects to make this significant,
but it's still a hit.

Not to mention that SupressFinalize will break derived objects that do need
a finalizer!

[Samuel R. Neff]

You can use the Finalizer to detect objects that are not properly
disposed.

Check out Sebastien Lorion's CSV reader [1]. He has code in there to
show when a disposable object is not disposed properly. Basically it
consists of adding this to your constructor:

_allocStack = new System.Diagnostics.StackTrace();

and this to your finalizer:

Debug.WriteLine("FinalizableObject was not disposed" +
_allocStack.ToString());

And instant failed-to-dispose detection with a stacktrace. Best to
put this code in conditional regions so it's only used in development.

Sam

[1] http://www.codeproject.com/cs/database/CsvReader.asp

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

[Jon Skeet [C# MVP]]

Samuel R. Neff <sa********@nomail.comwrote:

You can use the Finalizer to detect objects that are not properly
disposed.

<snip>

And instant failed-to-dispose detection with a stacktrace. Best to
put this code in conditional regions so it's only used in development.

Exactly - I wouldn't want to burden a production system with extra
finalizers. On the other hand, I don't like having too much different
between debug and production :(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Ben Voigt <rb*@nospam.nospamwrote:

I disagree - I *very* rarely need a finalizer, which makes the whole
Dispose(bool) extra method a bit pointless. Why add an extra level of
indirection *just in case* you need it - you won't have to change much
anyway even without the extra level of indirection.

The only reason I can think of to add this complexity without an
immediate need is if you're creating a class which others may derive
from. At that point you're in a different ballgame, as changing things
later becomes a versioning issue.

Still a non-issue. The derived class needs a finalizer if it holds
unmanaged resources, and it is no more difficult for the programmer to
implement the finalizer than to override your Dispose(bool) class. The
finalizer should be first introduced by the class holding unmanaged
resources, not some base class.

I was more thinking of introducing Dispose(bool) early on - but even
that can be done at the level of the first class that requires it, I
guess, with a call to base.Dispose() only when disposing is true.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Christof Nordiek]

"Jon Skeet [C# MVP]" <sk***@pobox.comschrieb im Newsbeitrag
news:MP*********************@msnews.microsoft.com. ..

I was more thinking of introducing Dispose(bool) early on - but even
that can be done at the level of the first class that requires it, I
guess, with a call to base.Dispose() only when disposing is true.

Even that would be impossible, if the Dispose is implemented explicitly. So
Dispose atleast should be implemented explicitly so that deriving classes
can call the base version while remapping or overriding Dispose.

Also, this can be a versioning issue, if a later version holds an unmanaged
resource directly, and so has to have its own finalizer.

Christof

[Samuel R. Neff]

But if Dispose is called like it should be, then the finalizer never
comes into play due to SuppresFinalize(). The reason for the
conditional compilation is that stack trace generation is an expensive
operation.

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

On Tue, 29 May 2007 20:57:18 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:

>Samuel R. Neff <sa********@nomail.comwrote:

>You can use the Finalizer to detect objects that are not properly
disposed.

<snip>

>And instant failed-to-dispose detection with a stacktrace. Best to
put this code in conditional regions so it's only used in development.

Exactly - I wouldn't want to burden a production system with extra
finalizers. On the other hand, I don't like having too much different
between debug and production :(

[Jon Skeet [C# MVP]]

Samuel R. Neff <sa********@nomail.comwrote:

But if Dispose is called like it should be, then the finalizer never
comes into play due to SuppresFinalize(). The reason for the
conditional compilation is that stack trace generation is an expensive
operation.

Even queuing things up on the finalizer queue and removing them is
something to avoid if there's no benefit though - that's why I'd make
the whole finalizer conditional.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Samuel R. Neff]

But if you call SuppressFinalize then it's as if the finalizer never
existed.. no?

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.


On Wed, 30 May 2007 19:13:05 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:

>Samuel R. Neff <sa********@nomail.comwrote:

>But if Dispose is called like it should be, then the finalizer never
comes into play due to SuppresFinalize(). The reason for the
conditional compilation is that stack trace generation is an expensive
operation.

Even queuing things up on the finalizer queue and removing them is
something to avoid if there's no benefit though - that's why I'd make
the whole finalizer conditional.

[Moty Michaely]

On May 31, 3:53 pm, Samuel R. Neff <[e-mail]:

But if you call SuppressFinalize then it's as if the finalizer never
existed.. no?

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

On Wed, 30 May 2007 19:13:05 +0100, Jon Skeet [C# MVP]

<[e-mail]:

Samuel R. Neff <[e-mail]:

But if Dispose is called like it should be, then the finalizer never
comes into play due to SuppresFinalize(). The reason for the
conditional compilation is that stack trace generation is an expensive
operation.

Even queuing things up on the finalizer queue and removing them is
something to avoid if there's no benefit though - that's why I'd make
the whole finalizer conditional.

Yes,
it's true.

[Jon Skeet [C# MVP]]

On May 31, 1:53 pm, Samuel R. Neff <[e-mail]:

But if you call SuppressFinalize then it's as if the finalizer never
existed.. no?

No - because SuppressFinalize can't be called until after the object
is created, and part of object creation is putting it onto the
finalizer queue if there's a finalizer.

Basically, there's a small performance hit for having a finalizer
which is always suppressed. It won't be significant in many cases, but
if you're creating millions of such objects, you don't want the
overhead.

Jon

[Samuel R. Neff]

I thought an object was put on the finalizer queue when it's detected
to no longer be referenced (directly or indirectly). I don't
understand how it would work that objects are put on the finalizer
queue upon instantiation.

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

On 31 May 2007 06:24:33 -0700, "Jon Skeet [C# MVP]" <sk***@pobox.com>
wrote:

>On May 31, 1:53 pm, Samuel R. Neff <[e-mail]:

>But if you call SuppressFinalize then it's as if the finalizer never
existed.. no?

No - because SuppressFinalize can't be called until after the object
is created, and part of object creation is putting it onto the
finalizer queue if there's a finalizer.

Basically, there's a small performance hit for having a finalizer
which is always suppressed. It won't be significant in many cases, but
if you're creating millions of such objects, you don't want the
overhead.

Jon

[Jon Skeet [C# MVP]]

On May 31, 4:14 pm, Samuel R. Neff <[e-mail]:

I thought an object was put on the finalizer queue when it's detected
to no longer be referenced (directly or indirectly). I don't
understand how it would work that objects are put on the finalizer
queue upon instantiation.

Yes, you're right - my mistake in terms of terminology. The principle
was apparently right though - from

http://www.bluebytesoftware.com/blog...3-20c06ae539ae

<quote>
Annotation (Herb Sutter): You really don't want to write a finalizer
if you can help it. Besides problems already noted earlier in this
chapter, writing a finalizer on a type makes that type more expensive
to use even if the finalizer is never called. For example, allocating
a finalizable object is more expensive because it must also be put on
a list of finalizable objects. This cost can't be avoided, even if the
object immediately suppresses finalization during its construction (as
when creating a managed object semantically on the stack in C++).
</quote>

It's this "list of finalizable objects" which I was erroneously
calling the finalizer queue. Apologies for the confusion. I wish I had
more details about it, but it's fairly hard to find comprehensive
documentation on this kind of thing :(

(The link is to a fantastic article about this whole topic though.
Well worth a read.)

Jon

[Samuel R. Neff]

One thing that's really important to me about the Dispose pattern is
that there is a defined standard about how IDisposable should be
implemented. When implemented that way, it works very well and
perhaps there is some perceived and minor performance hit but in
practice all of the MS classes that use IDisposable are implemented
per the standard so if you're saving yourself some small amount of
time by skipping the finalizer, it'll only help in your custom
classes.

The advantage of sticking to a standard is that all projects will be
coded the same way and you can move from project to project or company
to company and can expect things to be coded properly. If they're
not, there is a defined standard to fall back on which defines the
correct way.

When we interview candidates we always ask about the GC and
IDisposable and I'm pretty sure we've had less than 5 candidates out
of hundreds that can actually explain what IDisposable is for much
less how to correctly implement it in a custom class.

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

[Jon Skeet [C# MVP]]

Samuel R. Neff <sa********@nomail.comwrote:

One thing that's really important to me about the Dispose pattern is
that there is a defined standard about how IDisposable should be
implemented. When implemented that way, it works very well and
perhaps there is some perceived and minor performance hit but in
practice all of the MS classes that use IDisposable are implemented
per the standard so if you're saving yourself some small amount of
time by skipping the finalizer, it'll only help in your custom
classes.

The defined standard about how to implement IDisposable *avoids* a
finalizer though, unless you've got unmanaged resources - that's what
the link I posted before recommends.

The advantage of sticking to a standard is that all projects will be
coded the same way and you can move from project to project or company
to company and can expect things to be coded properly. If they're
not, there is a defined standard to fall back on which defines the
correct way.

Yes, but it doesn't include a finalizer unless you've got unmanaged
resources or expect a derived class to :)

When we interview candidates we always ask about the GC and
IDisposable and I'm pretty sure we've had less than 5 candidates out
of hundreds that can actually explain what IDisposable is for much
less how to correctly implement it in a custom class.

Yes, I've heard some pretty odd things in that respect...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Jon Skeet [C# MVP] wrote:

It's this "list of finalizable objects" which I was erroneously
calling the finalizer queue. Apologies for the confusion. I wish I had
more details about it, but it's fairly hard to find comprehensive
documentation on this kind of thing :(

The list of finalizable objects is actually called the "finalization
queue". This is a bit confusing, as it sounds as if it contained objects
that are up for finalization.

The list of object that is up for finalization is called the "freachable
queue".

http://msdn.microsoft.com/msdnmag/issues/1100/gci/

--
Göran Andersson
_____
http://www.guffa.com

[Jon Skeet [C# MVP]]

Göran Andersson <gu***@guffa.comwrote:

It's this "list of finalizable objects" which I was erroneously
calling the finalizer queue. Apologies for the confusion. I wish I had
more details about it, but it's fairly hard to find comprehensive
documentation on this kind of thing :(

The list of finalizable objects is actually called the "finalization
queue". This is a bit confusing, as it sounds as if it contained objects
that are up for finalization.

So I'd accidentally got the right terminology to start with. Cool :)
Maybe I'd seen the right way somewhere before and remembered it
subconsciously...

Shame so many articles use the more intuitive but incorrect terminology
then :(


--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too