Can lock into a dispose?

[BLUE]

I've a class A that implements IDisposable interface and has a method that
start a thread.
In Dispose(bool) can I use the lock keyword to wait for thread exit before
disposing resources it use or it's enough to pay attention when disposing
objects of type A from "consumer" classes?


Thanks,
Luigi.

 

[Nicholas Paldino [.NET/C# MVP]]

Luigi,

The use of lock is discouraged in a finalizer:

http://blogs.msdn.com/yunjin/archive/2005/07/05/435726.aspx

On top of that, if you take too long, the possibility exists that your
finalizer will be shut down anyways if it is the result of an app domain
shutting down:

http://www.bluebytesoftware.com/blog/PermaLink,guid,c3993fa3-4d71-414c-bfa3-bca600869018.aspx

I would recommend that you have a method that you call to wait for the
thread to terminate, then dispose of your object.

 

[BLUE]

It's a big big problem!

My GUI has a timer that is used to trigger data sync with a WS: when the
timer elapses it calls a method of the BLL which in turn call Sync method of
the DAL.
Sync create a thread that will synchronize data with the WS raising an event
for each step of the sync process (even an error).

Each layer (except for the presentation one) is a singleton class that
implements IDisposable interface.

So in the Closing event of the form, but also in the Dispose method I'll
call bll.Dispose() and in the BLL.Dispose method I'll call dal.Dispose().
Now in the case the timer has just elapsed and the user decide to close the
app I must wait sync to end, but how?
I could call a method in the closing event to disable the timer and I must
wait the last event (dataSynced) or the error event but how to stop closing
until synchronization?
I suppose I cannot make the user wait for a long time since it's not so good
and I cannot abort the thread since I'm using CF 1.x on WinCE 4.2!
Moreover this wait cannot be done in the form Dispose so it will never
dispose the dal!


Thank you for any help!
Luigi.

 

[Nicholas Paldino [.NET/C# MVP]]

I am curious, why are you going to have a singleton class that
implements IDispose? Those should be instances, because you are implying
that they have an explicit lifetime, which runs somewhat contrary to what a
singleton is.

You are going to have to make some sort of mechanism to cancel the
operation on the other thread in the case you want to shut down. You really
shouldn't be handling this in the Dispose method.

 

[BLUE]

I am curious, why are you going to have a singleton class that implements

IDispose?

Since I have a class that use an IntPtr and WinCE API calls to detect
insertion into the cradle I have to implement the dispose pattern
(dispose+finalize) for this singleton class: how to dispose unmanged
resources else?

I suppose the lifetime of all my singleton objects is the lifetime of the
application, but when the user closes it shouldn't I call all the dispose
methods?
If I use all singleton I have to forget IDisposable and Dispose pattern
implementation and the GC will do all for me?
I don't think it's a clean solution but tell me if I'm wrong!

I've used a mutex to synchronize the main thread (the GUI one) with the one
created for syncing: if syncThread starts before guiThread, the latter will
wait the first one, else guiThread will set doNotStart bool to true and when
the thread can access the critical section it simply returns.


Thank you for your help!
Luigi.

 

[Moty Michaely]

Since I have a class that use an IntPtr and WinCE API calls to detect
insertion into the cradle I have to implement the dispose pattern
(dispose+finalize) for this singleton class: how to dispose unmanged
resources else?

I suppose the lifetime of all my singleton objects is the lifetime of the
application, but when the user closes it shouldn't I call all the dispose
methods?
If I use all singleton I have to forget IDisposable and Dispose pattern
implementation and the GC will do all for me?
I don't think it's a clean solution but tell me if I'm wrong!

I've used a mutex to synchronize the main thread (the GUI one) with the one
created for syncing: if syncThread starts before guiThread, the latter will
wait the first one, else guiThread will set doNotStart bool to true and when
the thread can access the critical section it simply returns.

Thank you for your help!
Luigi.

Hi,

Nich, I think that nich must implement IDisposable in his singleton
classes.

About the lock in the finalizer:
I would try to avoid this somehow. I think that a time consuming
operations should be avoided either, somehow.

Nich?

 

[Christof Nordiek]

Luigi,

The use of lock is discouraged in a finalizer:

Dispose() is not Finalizer.

Dispose(bool) is called by the Finalizer of Form, but always with the value
false for the diposing parameter.

So, the if(disposing) statement would never be entered, when the Finalizer
is called. And Dispose of components shouldn't be called by the Finalizer
anyway.

Christof

 

[Moty Michaely]

Dispose() is not Finalizer.

Dispose(bool) is called by the Finalizer of Form, but always with the value
false for the diposing parameter.

So, the if(disposing) statement would never be entered, when the Finalizer
is called. And Dispose of components shouldn't be called by the Finalizer
anyway.

Christof

Hi,

What if things should be done without trusting the developer to call
Dispose?

Moty

 

[Christof Nordiek]

Hi,

What if things should be done without trusting the developer to call
Dispose?

Then the compononents (and their components ....) themselves are eligable
for finalization will be cleaned up by their own finalizer. So calling
Dispose isn't necessary anymore.
That's way classes like Form and Component implement the Dispose(bool)
method. By this inheriting classes can easily implement the cleanup of
managed resources, wich should only occur during disposing, and cleanup of
managed resources, wich has to occur during disposing aswell as during
finalization.

Christof

 

[Moty Michaely]

Then the compononents (and their components ....) themselves are eligable
for finalization will be cleaned up by their own finalizer. So calling
Dispose isn't necessary anymore.
That's way classes like Form and Component implement the Dispose(bool)
method. By this inheriting classes can easily implement the cleanup of
managed resources, wich should only occur during disposing, and cleanup of
managed resources, wich has to occur during disposing aswell as during
finalization.

Christof

But again,
What if the I need to serialize a class when it's about to be
disposed?
I would do it in the finalizer, right? (with dispose(false))
But either disposing is true or false, I would serialize the class,
wouldn't I?

Moty

 

[Christof Nordiek]

But again,
What if the I need to serialize a class when it's about to be
disposed?
I would do it in the finalizer, right? (with dispose(false))

No, this is not a good place for such things.
Finalizer should only clean up unmanaged resources, nothing else.

Also Dispose is also not a good place for serialization. It should only
cleanup managed and unmanged resources.
If you use Dispose for storing data or something else. Then you should
clearly communicate that to the caller of the class, and make it clear, that
data may be lost, if Dispose isn't called.
I don't know the scenario, you are talking about, but I guess, the is a
better way (like implementing an ISaveable interface or so).

Christof

 

[Chris Mullins [MVP]]

You can use a lock() (or a ReaderWriterLock, etc) in a Dispose() method.
There's no trouble with this at all.

A Dispose method, after all, is just a standard method running on the thread
of whatever called Dispose().

Where you really, really don't want to use a lock is inside a Finalizer. The
CLR uses a single thread to call finalizers, and if you block this thread,
finalization cannot happen and your application is now screwed.