Dispose and Singleton Pattern

[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.

 

[Peter Duniho]

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.

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

 

[Cowboy \(Gregory A. Beamer\)]

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!
|
*************************************************

 

[Peter Duniho]

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.

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

 

[Cowboy \(Gregory A. Beamer\)]

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.

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.

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.

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!
|
*************************************************

 

[Peter Duniho]

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.

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.

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.

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.

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

 

[Jon Skeet [C# MVP]]

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.

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

 

[Guest]

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.

 

[Peter Duniho]

You *can* use a finalizer for this - but it's not guaranteed to run.

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