GC and threads

  • Thread starter Thread starter Peter Morris [Droopy eyes software]
  • Start date Start date
P

Peter Morris [Droopy eyes software]

Hi all

If I understand correctly then the GC runs in its own thread and can kick in
at any time. Once it kicks in does it then run in the main thread or does
it remain in its own thread?
 
You understand incorrectly. The GC runs in the thread of whatever made the
request for allocation that required the GC. All other threads in the
process are suspended while it works.

-Chris
 
Hi Chris

Here is my situation:

I have written an object persistence framework for the PPC. Stuff I fetch
from the DB is held in an "ObjectSpace" and weakly referenced by a unique
ID. What I wanted to do was to ensure that anything fetched from the DB has
a minimum life of say 5 minutes, so that I can prevent fetching / collecting
/ refetching.

My plan was to do something like this

~ObjectLocator()
{
if (I am too young to die)
//Update my weakreference
ObjectSpace.RessurectObjectLocator(this);
else
//Remove the item from my Dictionary
ObjectSpace.UnregisterObjectLocator(this);
}

but I am concerned about my app making a request for an object locator and
then the GC kicking in. I certainly did experience more null references
when I took this approach.
 
Why are you doing this in the destructor? Keep in mind that the destructor is
called when GC tries to collect your object.
 
Also remember destructors only really need to be implemented when using
unmanaged resources from managed code...

Simon.
 
Desctructor is a confusing word. The ~syntax means that its
a finalizer, not to be mistaken with a C++ destructor.
 
Why are you doing this in the destructor? Keep in mind that the destructor
is
called when GC tries to collect your object.
Click to expand...

Isn't that the way you are supposed to implement object ressurection?

~MyClass()
{
this.ObjectSpace.RegisterLocator(this);
GC.ReRegisterForFinalize(this);
}


Pete
 
Back
Top