By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,179 Members | 2,192 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,179 IT Pros & Developers. It's quick & easy.

How can I release the resources allocated in Static constructors?

P: n/a
For example, I allocate some unmanaged resources in the static constructors,
then how can I properly release the resource before the application exit?

thx!
Nov 15 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
100
Hi Dolphin,
There is no static finalizer ot something like that. Why do you wary about
resources when the process termintaes? Usualy all resources are freed
automatically in that case. If you want to free them explicitly, you can
write designated static method, which can take care of this, but you have to
call this method by your self before shut the application down.

HTH
B\rgds
100

"Dolphin White" <sx***@163.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
For example, I allocate some unmanaged resources in the static constructors, then how can I properly release the resource before the application exit?

thx!

Nov 15 '05 #2

P: n/a
It would be pretty easy to do if you create a special class that knows how
to take care of the unmanaged resources. That way, instead of working with
the resources directly, you'll need to create a (static) instance of that
class in your static constructor. That instance will deallocate the
resources in its finalizer. To illustrate the idea:

class UnmanagedResourcesManager
{
public void AllocateResources() {...}
public void DeallocateResources() {...}
public UnmanagedResourcesManager()
{
AllocateResources();
}

~UnmanagedResourcesManager()
{
DeallocateResources();
}
}

class MyMainClass
{
private static UnmanagedResourcesManager s_manager;

static MyMainClass()
{
s_manager = new UnmanagedResourcesManager();
}
}
"Dolphin White" <sx***@163.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
For example, I allocate some unmanaged resources in the static constructors, then how can I properly release the resource before the application exit?

thx!

Nov 15 '05 #3

P: n/a
100
Hi Val,
Anyway a finalizer are not guaranteed to be executed when the process shuts
down.
AFAIK CLR gives some amount of time for all finalizers to finish when the
process ends and when this time interval expires CLR just shuts the process
down.

B\rgds
100
"Val Savvateev" <1@2.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
It would be pretty easy to do if you create a special class that knows how
to take care of the unmanaged resources. That way, instead of working with
the resources directly, you'll need to create a (static) instance of that
class in your static constructor. That instance will deallocate the
resources in its finalizer. To illustrate the idea:

class UnmanagedResourcesManager
{
public void AllocateResources() {...}
public void DeallocateResources() {...}
public UnmanagedResourcesManager()
{
AllocateResources();
}

~UnmanagedResourcesManager()
{
DeallocateResources();
}
}

class MyMainClass
{
private static UnmanagedResourcesManager s_manager;

static MyMainClass()
{
s_manager = new UnmanagedResourcesManager();
}
}
"Dolphin White" <sx***@163.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
For example, I allocate some unmanaged resources in the static

constructors,
then how can I properly release the resource before the application exit?
thx!


Nov 15 '05 #4

P: n/a
Below is a quote from MSDN. My understanding is that it really depends on
how the process is terminated. When it is terminated in a regular way
(trough "closing" or "ExitProcess"), the runtime is always trying to
finalize the objects. When the process just gets killed (though
"TerminateProcess"), well... there's no program that would be able to do any
clean-up in that case. :)

"The Finalize method might not run to completion or might not run at all in
the following exceptional circumstances:

a.. Another finalizer blocks indefinitely (goes into an infinite loop,
tries to obtain a lock it can never obtain and so on). Because the runtime
attempts to run finalizers to completion, other finalizers might not be
called if a finalizer blocks indefinitely.
b.. The process terminates without giving the runtime a chance to clean
up. In this case, the runtime's first notification of process termination is
a DLL_PROCESS_DETACH notification. "
"100" <10*@100.com> wrote in message
news:eT**************@TK2MSFTNGP10.phx.gbl...
Hi Val,
Anyway a finalizer are not guaranteed to be executed when the process shuts down.
AFAIK CLR gives some amount of time for all finalizers to finish when the
process ends and when this time interval expires CLR just shuts the process down.

B\rgds
100
"Val Savvateev" <1@2.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
It would be pretty easy to do if you create a special class that knows how
to take care of the unmanaged resources. That way, instead of working with the resources directly, you'll need to create a (static) instance of that class in your static constructor. That instance will deallocate the
resources in its finalizer. To illustrate the idea:

class UnmanagedResourcesManager
{
public void AllocateResources() {...}
public void DeallocateResources() {...}
public UnmanagedResourcesManager()
{
AllocateResources();
}

~UnmanagedResourcesManager()
{
DeallocateResources();
}
}

class MyMainClass
{
private static UnmanagedResourcesManager s_manager;

static MyMainClass()
{
s_manager = new UnmanagedResourcesManager();
}
}
"Dolphin White" <sx***@163.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
For example, I allocate some unmanaged resources in the static

constructors,
then how can I properly release the resource before the application

exit?
thx!



Nov 15 '05 #5

P: n/a
Oh, my god! thx!
I have used this way in my VC programs so often, buy I am immersion in the
static constructor of C# and forgot it. :(

Thank you for your comment!
"Val Savvateev" <1@2.com> дʼ
news:%2****************@tk2msftngp13.phx.gbl...
It would be pretty easy to do if you create a special class that knows how
to take care of the unmanaged resources. That way, instead of working with
the resources directly, you'll need to create a (static) instance of that
class in your static constructor. That instance will deallocate the
resources in its finalizer. To illustrate the idea:

class UnmanagedResourcesManager
{
public void AllocateResources() {...}
public void DeallocateResources() {...}
public UnmanagedResourcesManager()
{
AllocateResources();
}

~UnmanagedResourcesManager()
{
DeallocateResources();
}
}

class MyMainClass
{
private static UnmanagedResourcesManager s_manager;

static MyMainClass()
{
s_manager = new UnmanagedResourcesManager();
}
}
"Dolphin White" <sx***@163.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
For example, I allocate some unmanaged resources in the static

constructors,
then how can I properly release the resource before the application exit?
thx!


Nov 15 '05 #6

P: n/a
100
Hi Val,
Even though you might close the application in the *normal way* finalizers
are not quarantee to be executed.
Following is a quote form the Jeffrey Richter'a article "Garbage Collection:
Automatic Memory Management in the Microsoft .NET Framework", which can be
found at
http://msdn.microsoft.com/msdnmag/issues/1100/gci/ - Part I and
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/ - Part II

"When an application terminates, some objects are still reachable and will
not have their Finalize method called. This can happen if background threads
are using the objects or if objects are created during application shutdown
or AppDomain unloading. In addition, by default, Finalize methods are not
called for unreachable objects when an application exits so that the
application may terminate quickly. Of course, all operating system resources
will be reclaimed, but any objects in the managed heap are not able to clean
up gracefully. You can change this default behavior by calling the System.GC
type's RequestFinalizeOnShutdown method. However, you should use this method
with care since calling it means that your type is controlling a policy for
the entire application."

I couldn't find the method RequestFinalizeOnShutdown, though.

What is not mentioned in the article, but can be found in the Jeffrey
Richter's book "Applied Microsoft.Net Framework Programming in... " is that
for every finalizer CLR gives 2 sec to terminate if a finalizer fails to
terminate in 2 sec the application is shuted down and no other finalizers
are called. For all finalizers CLR gives 40 sec to terminate and when this
time expires the application is shuted down and the rest of the finalizers
remain uncalled.
This time intervals are subject to change and this values are correct for
the time JR was writing the book.

Any ways the time intervals look big enough not to warry about them, but
there are still chances to have the finalizers not called. Anyway, since the
application is terminated and all umanaged resources will be reclaimed I
think the best is not to warry about them.
If the unmanaged resource is not one of the *windows unmanaged resources* (I
mean is some custom device which has to be shuted down explicitly) I think
you should be very carefull before using finalizers for that.

To finalize ;) my post I just want to remind you that MS says the
programmers should avoid using finalizers *only* for cleaning the unmanaged
resources. IDisposable pattern should be used instead.

HTH
B\rgds
100

"Val Savvateev" <1@2.com> wrote in message
news:Oo**************@TK2MSFTNGP12.phx.gbl...
Below is a quote from MSDN. My understanding is that it really depends on
how the process is terminated. When it is terminated in a regular way
(trough "closing" or "ExitProcess"), the runtime is always trying to
finalize the objects. When the process just gets killed (though
"TerminateProcess"), well... there's no program that would be able to do any clean-up in that case. :)

"The Finalize method might not run to completion or might not run at all in the following exceptional circumstances:

a.. Another finalizer blocks indefinitely (goes into an infinite loop,
tries to obtain a lock it can never obtain and so on). Because the runtime
attempts to run finalizers to completion, other finalizers might not be
called if a finalizer blocks indefinitely.
b.. The process terminates without giving the runtime a chance to clean
up. In this case, the runtime's first notification of process termination is a DLL_PROCESS_DETACH notification. "
"100" <10*@100.com> wrote in message
news:eT**************@TK2MSFTNGP10.phx.gbl...
Hi Val,
Anyway a finalizer are not guaranteed to be executed when the process

shuts
down.
AFAIK CLR gives some amount of time for all finalizers to finish when the
process ends and when this time interval expires CLR just shuts the

process
down.

B\rgds
100
"Val Savvateev" <1@2.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
It would be pretty easy to do if you create a special class that knows

how to take care of the unmanaged resources. That way, instead of working with the resources directly, you'll need to create a (static) instance of that class in your static constructor. That instance will deallocate the
resources in its finalizer. To illustrate the idea:

class UnmanagedResourcesManager
{
public void AllocateResources() {...}
public void DeallocateResources() {...}
public UnmanagedResourcesManager()
{
AllocateResources();
}

~UnmanagedResourcesManager()
{
DeallocateResources();
}
}

class MyMainClass
{
private static UnmanagedResourcesManager s_manager;

static MyMainClass()
{
s_manager = new UnmanagedResourcesManager();
}
}
"Dolphin White" <sx***@163.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
> For example, I allocate some unmanaged resources in the static
constructors,
> then how can I properly release the resource before the application

exit?
>
> thx!
>
>



Nov 15 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.