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...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...600869018.aspx

I would recommend that you have a method that you call to wait for the
thread to terminate, then dispose of your object.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"BLUE" <bluewrote in message news:OT******** ******@TK2MSFTN GP04.phx.gbl...

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.

[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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"BLUE" <bluewrote in message
news:u%******** **********@TK2M SFTNGP04.phx.gb l...

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.

[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+finali ze) 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]

On May 20, 4:11 pm, "BLUE" <bluewrote:

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+finali ze) 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]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omschrieb
im Newsbeitrag news:57******** *************** ***********@mic rosoft.com...

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]

On May 21, 10:37 am, "Christof Nordiek" <[e-mail] wrote:

"Nicholas Paldino [.NET/C# MVP]" <[e-mail] d.caspershouse. comschrieb
im Newsbeitragnews :57************ *************** *******@microso ft.com...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

Hi,

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

Moty

[Christof Nordiek]

"Moty Michaely" <Mo*****@gmail. comschrieb im Newsbeitrag
news:11******** **************@ n15g2000prd.goo glegroups.com.. .

>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?

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]

On May 21, 12:47 pm, "Christof Nordiek" <[e-mail] wrote:

"Moty Michaely" <Moty...@gmail. comschrieb im Newsbeitragnews :11************ **********@n15g 2000prd.googleg roups.com...

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?

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