Dispose and Singleton Pattern

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I have a singleton object which contains a ref to a object with a dispose
method on it. I realise that ideally I should call dispose on this object but
since the singleton could be referenced by many clients when should I do this?

I can only think I need to implement some sort of ref counting but I'd like
to avoid this and just clean up the object when my process is shutdown.

If you can offer any advice I'd appreciate it.
 
Hi,

I have a singleton object which contains a ref to a object with a dispose
method on it. I realise that ideally I should call dispose on this object but
since the singleton could be referenced by many clients when should I do this?

I can only think I need to implement some sort of ref counting but I'd like
to avoid this and just clean up the object when my process is shutdown.

If you can offer any advice I'd appreciate it.
Click to expand...

It just depends on how your application shuts down and what sort of
rules you've imposed in your design.

If you have a point in your shutdown where you know the singleton won't
be used again (retrieved or accessed via a previously retrieved
reference), then you can just dispose what you need to there.
Otherwise, you will need to build into your design some way for any
code that might access the singleton to signal that it is in fact done
with it (or perhaps simply done altogether, depending on the structure
of the application and your needs).

Ref-counting can be one way to do this. Variations on the theme
include having some list of active threads that might be using the
singleton, and waiting for each to complete after you've instructed
them to stop processing.

Another option is to simply make the object safe for use after
disposal. Define some non-fatal behavior for it to do if some code
tries to use it after it's been disposed, and then just let whatever
code wants to use it try.

Which is most appropriate depends a lot on your needs and the
architecture of your program.

Pete
 
Do not dispose a singleton after use. It is designed to sit in memory as
long as the application runs. You can dispose when the application shuts
down, however, as it should be set to persist when it goes out of scope.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
 
Do not dispose a singleton after use. It is designed to sit in memory as
long as the application runs. You can dispose when the application shuts
down, however, as it should be set to persist when it goes out of scope.
Click to expand...

A singleton by definition would never go out of scope, since at least
one reference to the instance would always be stored in a static
variable.

As far as the "dispose when the application shuts down", since in this
context "application" is the same as "process", that's exactly the
scenario the OP is asking about.

Consider a singleton class that needs to do some final cleanup. Many
classes would be safe just letting them get freed by the system when
the process exits, but if the singleton class needs to be disposed or
otherwise handle some sort of last cleanup (flushing a file buffer,
gracefully closing a TCP connection, etc.) then some more explicit
mechanism has to be used.

Pete
 
Peter Duniho said:
A singleton by definition would never go out of scope, since at least one
reference to the instance would always be stored in a static variable.
Click to expand...

Once the application is dead, there is no need to keep a singleton alive.
That would be my definition of "out of scope" in this case.
As far as the "dispose when the application shuts down", since in this
context "application" is the same as "process", that's exactly the
scenario the OP is asking about.
Click to expand...

He also asked about ref counters, etc. to determine when to dispose, so I
felt it was a fair answer.
Consider a singleton class that needs to do some final cleanup. Many
classes would be safe just letting them get freed by the system when the
process exits, but if the singleton class needs to be disposed or
otherwise handle some sort of last cleanup (flushing a file buffer,
gracefully closing a TCP connection, etc.) then some more explicit
mechanism has to be used.
Click to expand...

Sure. In generally, dispose is a good pattern when you have unmanaged
resources. If this singleton is merely state for an application, letting it
clean up without intervention would be best. On that, I think we are both in
agreement.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
 
Once the application is dead, there is no need to keep a singleton alive.
That would be my definition of "out of scope" in this case.
Click to expand...

But what if you need to do something special before the application dies?
He also asked about ref counters, etc. to determine when to dispose, so I
felt it was a fair answer.
Click to expand...

I'm just pointing out that in your own post, the exception you applied
to the general advice you offered was specifically the scenario the OP
is dealing with.

I didn't see anything wrong with the general advice you offered, except
that even you acknowledged immediately that it wasn't applicable here.
:)
Sure. In generally, dispose is a good pattern when you have unmanaged
resources.
Click to expand...

This isn't just about disposing. It's about anything the singletone
might have to do before being discarded.
If this singleton is merely state for an application, letting it
clean up without intervention would be best. On that, I think we are both in
agreement.
Click to expand...

Right...but how does the singleton know to clean up? It's not going to
get any notification when the application exits, without doing some
extra work.

Pete
 
Right...but how does the singleton know to clean up? It's not going to
get any notification when the application exits, without doing some
extra work.
Click to expand...

You *can* use a finalizer for this - but it's not guaranteed to run.
For instance, if another finalizer decides to take a long time, the
process could decide to abandon running finalizers.

I don't know if the AppDomain.DomainUnload event is of any use here -
the docs say it doesn't get fired on the default domain, which is most
likely the domain being used :(

There's AppDomain.ProcessExit as well, which has a few different
caveats, but may well be the right way to go.

Jon
 
Thanks for the advice guys. I've managed to change the application logic to
give me a sensible point to call dispose, this will mean I don't need to ref
count or hook up events for AppDomain exits etc.
 
You *can* use a finalizer for this - but it's not guaranteed to run.
Click to expand...

I guess that depends on one's definitions of "can" and "this". :)

Obviously, I'd prefer a more explicit implementation. I think usually
that's going to be a doable design.

Pete
 
Back
Top