Re: Finalizer implementation - C# Discussion Boards

Help anyone?!? Confused | :confused:

Hello everyone,

Two conflicting points about how to implement Finalizer, which one is correct?

1.

I always heard from people that in Finalizer we should not refer to any other objects, since the order of Finalizer is non-determistic, means the referred object in Finalizer might not alive any more.

2.

From the following article from MSDN, seems we are safe to refer to any wrapped objects (in my understanding, it means referring to member variables in Finalizer is always safe)?

http://msdn2.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic2

--------------------
"How Finalization Affects Collection
When the garbage collector first encounters an object that is otherwise dead but still needs to be finalized it must abandon its attempt to reclaim the space for that object at that time. The object is instead added to a list of objects needing finalization and, furthermore, the collector must then ensure that all of the pointers within the object remain valid until finalization is complete.
....
Since the internal object pointers must remain valid, not only will the objects directly needing finalization linger in memory but everything the object refers to, directly and indirectly, will also remain in memory. If a huge tree of objects was anchored by a single object that required finalization, then the entire tree would linger, potentially for a long time as we just discussed."
--------------------

thanks in advance,
George

Not sure how you're making the jump from the quoted text to your second point...but...

1. The order of finalization is non-determistic, so there is no guarantee that if you access another object from within your finalizer that it will still be available.

2. If by "wrapped objects" you mean an object that your are internally maintaining, it is safe under certain circumstances.

Finalizers shouldn't do anything more than ensure that memory is cleaned up by calling the appropriate Dispose methods (or other means for unmanaged code). Almost all of the assumptions that can be made about the internal state of the .NET runtime (and your object) that would normally be valid are not when running in a finalizer.

What is it that you're trying to do that you think requires the use of a finalizer? In the large majority of cases, it isn't necessary to write one.

Scott.

—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Forum Guidelines] [Articles] [Blog]

Scott's assessment is correct and in addition, in Microsoft's book CLR via CSharp[^] the advice given by the author is that a finalizer is used to ensure that native resources are released. And the only native resources that are mentioned in the text are Handles. So as I understand it, unless you are using items by their windows handles, don't bother. Highly recommend getting the book.

Scott P

"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand

Cool, carbon_golem!

1.

One further question, if in my class, there is a StreamWriter data member, in the Finalizer method, if I do not close the StreamWriter, there should not be any resource leak, right? (because the Finalizer of StreamWriter itself will clean up native file handle resource wrapped by StreamWriter?)

2.

So, C# I/O class like StreamWriter is managed resource, not unmanaged resource?

regards,
George

George_George wrote:
1.

One further question, if in my class, there is a StreamWriter data member, in the Finalizer method, if I do not close the StreamWriter, there should not be any resource leak, right? (because the Finalizer of StreamWriter itself will clean up native file handle resource wrapped by StreamWriter?)

Fairly certain that's the case.

George_George wrote:
2.

So, C# I/O class like StreamWriter is managed resource, not unmanaged resource?

Yes.

Scott P

"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand

Thanks carbon_golem,

I have made some further study.

http://msdn2.microsoft.com/en-us/library/ddae83kx.aspx

Seems that we can only access base.Finalize in Finalizer method of current class? Any comments? Please feel free to correct me if I am wrong. Smile | :)

--------------------
An object's Finalize method should not call a method on any objects other than that of its base class.
--------------------

regards,
George

That's right. The garbage collection can't guarantee that anything will be available - think of the case that your finalizer is the absolute last thing that is done in your application before it shuts down, all other resources have been reclaimed including all the members inside your class. That's what you have to deal with. The purpose of a finalizer is to give you one last chance to free any native resources that your class may use. One case is that you decide that you want a class with a Hook created by CreateWindowsHookEx and you own that hook. Finalizer implementation would be advised because you are using a native resource directly, and you don't want to leak that resource. As long as the finalizer exists, the runtime will call it, you don't need to. One special case is when you release the resource in your Dispose method, at then end of the Dispose, make a call to GC.SupressFinalize and the finalizer won't get called. Getting the idea?

If your class is using a built in .NET class that owns native resources, you can be pretty sure that .NET takes care of the finalizer for you. IF you implement a finalizer, the runtime calls it. The same holds true for the finalizers that .NET is using. Oh, one last thing, if you do decide to use a native resource by handle, look into .NET's SafeHandle classes, and that will shed some insight on what you're doing.

Again
1) If you implement a finalizer, the runtime will call it when it's being reclaimed by the garbage collector - UNLESS you have explicitly made a call to GC.SupressFinalize.
2) Implement a finalizer when you are using Native Resources, notably Handles.
3) You can never be sure what other data will be available when your finalizer is called.
4) Get Lutz's Reflector, and see how .NET does it's finalizers. I won't answer questions about Reflector, stfw. Smile | :)

Scott P

"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand

Cool, Scott!

I agree with you in Finalizer we should only deal with releasing of native resource. I have got CLR via C# book, and referred the chapter 20, GC chapter. For the managed resource in Finalizer, it is suggested we only access the ones which do not have Finalizer method, because if there is finalizer method, the GC order of current object and referred object is not decided.

(section "Using Finalization with Managed Resources").

Do you agree or have any comments?

(So, our conclusion is, dealing with unmanaged resource and manged resource without Finalizer?)

regards,
George

That's it. Bravo.

"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand

Thanks carbon_golem,

It is clear now.

regards,
George

Hi Scott,

Scott Dorman wrote:
1. The order of finalization is non-determistic, so there is no guarantee that if you access another object from within your finalizer that it will still be available.

2. If by "wrapped objects" you mean an object that your are internally maintaining, it is safe under certain circumstances.

The wrapped object I mean member variable of a class. From your above comments, I think your points are, it is not safe to access member variable of a class inside Finalizer method.

But from this link, it seems it is safe to access, since all the referred objects are retained live in Finalier. This why I am confused.

I think your points are conflicting with what I mentioned above and quoted below. Any comments?

http://msdn2.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic2[^]

--------------------
"How Finalization Affects Collection"

Since the internal object pointers must remain valid, not only will the objects directly needing finalization linger in memory but everything the object refers to, directly and indirectly, will also remain in memory. If a huge tree of objects was anchored by a single object that required finalization, then the entire tree would linger, potentially for a long time as we just discussed."
--------------------

regards,
George

I see your point and I think I understand where you are getting confused.

Even though the internal object pointers remain valid, there is still no guarantee that when you go to access them in the finalizer they will still be valid. From my article[^],

Since finalizers run non-deterministically, there is no ordering among them so you can't rely on them being executing in a specific order. You should not access any finalizable objects your type may have a reference to because they may have already been finalized. As a result, you should only free unmanaged resources that your object owns.

Scott.

—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Forum Guidelines] [Articles] [Blog]

Cool, Scott!

From learning in this forum, I think the best practice should be (also mentioned in the book CLR via C# version 2),

1. We can access and free unmanaged resource;
2. Base class Finalizer (code implicitly generarted);
3. Manages resource without Finalizer;

It is not safe to access,

Manages resource with Finalizer, since Finalizer execution order are non-determistic.

Any comments? Agree? Smile | :)

regards,
George

Glad you were able to get what you needed. I think that overall I would agree with those statements.

Thanks,

Scott.

Scott.

—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Forum Guidelines] [Articles] [Blog]

"overall", Smile | :)

Any disagree with Jeffrey's pointer. Smile | :)

regards,
George

George_George wrote:
Any disagree with Jeffrey's pointer.

Nope, just like to keep my options open. Smile | :)

Scott.

—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Forum Guidelines] [Articles] [Blog]

It is cool, Scott! Smile | :)

Thanks for your help and patience on this thread.

regards,
George

Hello everyone,

The conclusion, root in managed heap is always alive. Is always correct?

thanks in advance,
George

George_George,

You seem to be asking ALOT of questions. Might it be better to just get a book?

Regards,
Gareth.

Hi Gareth,

I have the book Programming C# and CLR VIA C#, but what I asked is not explicitly mentioned in the books. This is what I studied and thought, so I want to come here to listen to gurus like you about whether my understanding is correct. Smile | :)

Any comments?

regards,
George

Well what's the point of this forum? I have a book on PHP yet I still ask a lot of PHP questions at phpfreaks.com

Hi George,

these are all starting points when a GC scans for reachable objects:
- the root of the heap (or every heap if there are many holding managed objects)
- the current stack pointer for every thread in the process
- the CPU registers (holding data for the current thread, unless the GC itself is
running in a thread, so the current thread does not belong to the process of interest)

From each of these everything that could be a reference needs to be followed, just like
a web crawler would do when you give it one or more URLs.

Every object that one does not find with the above is declared dead and can be collected;
doing it this way avoids any problems with cyclic references (A holds ref to B, and B holds
ref to A; both are dead if the above algorithm never leads to either A or B).

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.

Thanks Luc,

1.

Luc Pattyn wrote:
the root of the heap (or every heap if there are many holding managed objects)

Sorry, I am confused, GC scans from the root of the heap (I thin it should scan from lowest address of the heap to the highest address of the heap), and scans for what? You only mentioned from where, but never mentioned what to do. Smile | :)

2.

Luc Pattyn wrote:
the current stack pointer for every thread in the process

Confusion the same as in (1) -- scan from current stack pointer to do what? Do you mean from the current stack pointer to scan for all available stack local variables?

regards,
George

Hi George,

1.
I was inaccurate for the heap; most systems use a variation of this scheme:
- stop all threads;
- walk the heap ONLY to mark all objects as dead;
- then perform the algorithm based on the thread stacks (and CPU registers),
marking the live objects as not-dead (see below);
- resume all threads;
- walk the heap to delete all objects that are still marked dead.
There are different schemes (e.g. for better real-time behavior, not really a Windows thing),
for better performance (with generations, implemented in MS .NET), etc. Some are completely
different (e.g. based on reference counts, which is very hard to get right
in cyclic situations). The last step (delete) can be delegated to another (low-prio)
thread.

2.
stack is easy: for each new thread the stack pointer is initialized to some value ("stack
base") and every time something gets pushed onto the stack, the pointer moves away from
that base (either up or down, depends on the CPU architecture).
So the GC will search the stack from its current position towards the stack base,
and threat every 4 or 8 bytes as a potential reference. If it falls outside the heaps,
if is definitely not a reference, hence it gets skipped. If it falls inside the range
of one of the heaps, some extra fields are checked, and if they match it is considered
an object, hence marked alive.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.