Idea: GC and IDisposable

Laura T. <LT_stop@yahoo.com> wrote:
> > Not necessarily. From the docs for IDisposable:
> >
> > <quote>
> > Use this method to close or release unmanaged resources such as files,
> > streams, and handles held by an instance of the class that implements
> > this interface. This method is, by convention, used for all tasks
> > associated with freeing resources held by an object, or preparing an
> > object for reuse.
> > </quote>
> >
> > Note the "or preparing an object for reuse". I can't think of any
> > examples where that actually *is* the use of IDisposable, but it would
> > be legal according to the docs.
>
> Object pooling perhaps?

Yes, that could be a potential use - just one I happen not to have come
across

--
Jon Skeet - <skeet@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

Hilton wrote:
> "Göran Andersson" <guffa@guffa.com> wrote in message
> news:eUOZsSv$HHA.3848@TK2MSFTNGP05.phx.gbl...
>> The IDisposable interface is intended for the developer to be able to
>> control the life cycle of an object. That doesn't only mean to kill it in
>> a predictable way, but sometimes also to keep it alive in a predictable
>> way.
>
> Just holding a reference to it will keep it alive as it always has.
>
> Hilton
>

Just holding a reference is not enough. You have to actually use the
reference.

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

On 25 Sep., 12:00, Jon Skeet [C# MVP] <sk...@pobox.com> wrote:
> KWienhold <hedov...@trashmail.net> wrote:
> > That might be a reason, but in my mind it would violate the intent of
> > IDisposable. Maybe I'm nitpicking here, but if I saw someone call
> > Dispose on an instance and then use that instance afterwards I'd be
> > seriously confused.
> > Disposing something tells me that the instance is left in an unknown
> > state and shouldn't be used.
>
> Not necessarily. From the docs for IDisposable:
>
> <quote>
> Use this method to close or release unmanaged resources such as files,
> streams, and handles held by an instance of the class that implements
> this interface. This method is, by convention, used for all tasks
> associated with freeing resources held by an object, or preparing an
> object for reuse.
> </quote>
>
> Note the "or preparing an object for reuse". I can't think of any
> examples where that actually *is* the use of IDisposable, but it would
> be legal according to the docs.
>
> --
> 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

As usual, you are right of course
Its just that I have never come across IDisposable being used in this
fashion, so it would at least raise a red flag in my mind.
I never actually noticed this in the documentation, but its something
to keep in mind. Up to now I would have not thought of implementing
IDisposable to indicate an object that could be cleaned and then
reused.
I'm still left wondering wether this would be a good idea though,
since it elude other people reading my code and having a seperate
method for that case seems clearer.

Kevin Wienhold

On Sep 25, 4:06 am, Peter Duniho <NpOeStPe...@NnOwSlPiAnMk.com> wrote:
> Doug Semler wrote:
> > [...]
> > Whoa, wait. Finalize should NEVER call Dispose to clean up managed
> > resources, since the maaged resource references may no longer exist!
>
> I don't disagree. But I was just assuming that we were talking about
> unmanaged resources here. After all, those are the ones that cause the
> most trouble if not disposed properly.
>
> Did I miss something?

Huh..*we* may have known that, but some others lurking in the thread
may have interpreted the statement made to mean that it is safe to
call implement a Finalizer that calls Dispose() without regard to
whether the Finalize() method was doing the calling.

I actually like the C++/CLI's compiler's way of "automagically"
implementing the IDisposable pattern if you insert into your classes:

~ClassName()
{
// Dispose managed objects
this->!ClassName(); // call Finalizer
}

!ClassName()
{
// Clean up unmanaged stuff
}

The compiler is nice enough to implement IDisposable, Dispose(bool),
proper calling sequence, and just for good measure a
GC.SuppressFinalize in there on the explicit Dispose call <g>

>> The GC handles cleaning up of managed resources just fine as far as I
>> know, so I don't really understand why one would even use IDisposable
>> on a class containing only managed resources.

For any Compact Framework object containing an Image or a Bitmap it's really
useful, as those classes holdnative resources that you often want to get rid
of as soon as possible in a memory-constrained device.

Also maybe for controlling the lifetime of something in a using{...}
pattern? Maybe?


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

On Sep 25, 4:00 pm, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
> >> The GC handles cleaning up of managed resources just fine as far as I
> >> know, so I don't really understand why one would even use IDisposable
> >> on a class containing only managed resources.
>
> For any Compact Framework object containing an Image or a Bitmap it's really
> useful, as those classes holdnative resources that you often want to get rid
> of as soon as possible in a memory-constrained device.
>
> Also maybe for controlling the lifetime of something in a using{...}
> pattern? Maybe?

I would imagine that KWienhold meant that you don't (usually)
implement IDisposable on a class which only references managed
resources, directly or indirectly. If you've got a class which itself
"owns" some other IDisposables, that container class should also
implement IDisposable.

Jon

Certainly, but again for any lurkers I want it to be clear that there are
good reasons for a class that contains only managed classes to still
implement IDisposable.

I must say, cross-posting in groups other that just the CF (where I and the
OP typically reside) brings in some fresh perspectives and provides some
great insights. We should do this more often.

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com


"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:1190732879.598756.224170@g4g2000hsf.googlegro ups.com...
> On Sep 25, 4:00 pm, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
>> >> The GC handles cleaning up of managed resources just fine as far as I
>> >> know, so I don't really understand why one would even use IDisposable
>> >> on a class containing only managed resources.
>>
>> For any Compact Framework object containing an Image or a Bitmap it's
>> really
>> useful, as those classes holdnative resources that you often want to get
>> rid
>> of as soon as possible in a memory-constrained device.
>>
>> Also maybe for controlling the lifetime of something in a using{...}
>> pattern? Maybe?
>
> I would imagine that KWienhold meant that you don't (usually)
> implement IDisposable on a class which only references managed
> resources, directly or indirectly. If you've got a class which itself
> "owns" some other IDisposables, that container class should also
> implement IDisposable.
>
> Jon
>

Brian Gideon wrote:
> On Sep 24, 4:48 pm, Göran Andersson <gu...@guffa.com> wrote:
>> The IDisposable interface is intended for the developer to be able to
>> control the life cycle of an object. That doesn't only mean to kill it
>> in a predictable way, but sometimes also to keep it alive in a
>> predictable way.
>
> That was a very well thought out response.
>

Thanks.

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

On Sep 24, 10:35 pm, "Hilton" <nos...@nospam.com> wrote:
> "Göran Andersson" <gu...@guffa.com> wrote in message
>
> news:eUOZsSv$HHA.3848@TK2MSFTNGP05.phx.gbl...
>
> > The IDisposable interface is intended for the developer to be able to
> > control the life cycle of an object. That doesn't only mean to kill it in
> > a predictable way, but sometimes also to keep it alive in a predictable
> > way.
>
> Just holding a reference to it will keep it alive as it always has.
>
> Hilton

That's not really what he meant by "alive" though.

Hilton wrote:
> "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
> news:e%23UVlTv$HHA.2004@TK2MSFTNGP06.phx.gbl...
>> Agreed. Implementing IDisposable is a flag to the consumer, not the GC.
>> The GC doesn't know or care about IDisposable objects. If it did, then
>> you would have the issues currently surrounding Finalizers to content with
>> (and that's the exact reason it's recommended that you implement
>> IDisposable instead of using a Finalizer).
>>
>> There's no way to "automate" this process without causing pain for those
>> of us who like performance or adding the requirement of multiple
>> collection cycles to release resources.
>
> Sure there is. How would you call Dispose? You'd call it on an object -
> right? That means that it would not be GC'd (yet) since you are holding a
> reference to it, so everything works just fine as it always has.

Altually, holding a reference is not enough to keep an object alive. You
have to actually use the reference for it to count as an active
reference. As soon as the GC can determine that the reference will never
be used again, the object can be garbage collected.

With your suggestion, to keep an object alive you would have to call
GC.KeepAlive(obj) where you would now call obj.Dispose(). It's no less
work for the developer, and the GC would have to work a lot harder.

> Now when
> this object can be GC'd (no refs etc), then 'my' logic kicks in, disposes
> the object and frees the memory ***IF*** it hasn't already been disposed.
> It's just a safety net, not a new paradigm.
>
> Your code is not affected, you can continue to optimize, but the GC will
> dispose of any objects that need to be disposed, but weren't. Sounds good
> to me.

A finalizer is usually used as a safety net in the Disposable pattern,
to at least try to free the unmanaged resources in case someone forgets
to call Dispose. The finalizer is never supposed to be used, however, as
it uses more resources than calling Dispose. In this pattern the Dispose
method calls GC.SupressFinalizer to remove the object from the
finalization list.

If the Dispose method is not called, the object remains in the
finalization list. When the GC is about to collect the object, it has to
put it in the FReachable queue instead, where a separate thread will
eventually execute the finalzer before the object can be collected. As
the object can't be collected right away, it might also have to be
promoted to the next GC generation, which means that the entire object
is moved in memory.

If you want to use the finalizer instead of the Disposable pattern, the
GC would have to become a lot more aggressive when running the
finalzers, starting a lot of threads with rather high priority to ensure
that it doesn't take too long before the finalizers are executed. This
of course means that the performance of an application would be much
less predictable, as all finalizers would have to run right away,
instead of when there is low pressure on the system.

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