Object life question [VB.NET 2005]

[Sid Price]

I have been reading about the managed heap and garbage collection and I have
a question. I have a class that has a very simple task and that is to send a
UDP message to a remote computer. The caller simply creates an instance of
the class with appropriate parameters and the class takes care of the
sending. The caller creates this instance and it goes out of scope almost
right away. In the "New" sub of the class a thread is created and started to
send the command data, this thread exits once it is done. So, the question
is, will the GC detect that the object is no longer in use when the thread
exits and dispose of it or is it "disposable" as soon as the object goes out
of scope?
The class "Trigger" is like this:
Public Class Trigger
Public Sub New(byval strAddress as string, byval strCommand as string)
mThread = new Thread(addressof SendCommand)
mThread.Start()
End Sub
Private Sub SendCommand()
... Do work here
End Sub
... other class methods etc
End Class
And the is like:
Public Sub VM_Send(byval strAddress as string, byval strData as string)
Dim oCommand as new Trigger(strAddress,strData)
End Sub
Thanks,
Sid.

 

[Tom Shelton]

I have been reading about the managed heap and garbage collection and I have
a question. I have a class that has a very simple task and that is to send a
UDP message to a remote computer. The caller simply creates an instance of
the class with appropriate parameters and the class takes care of the
sending. The caller creates this instance and it goes out of scope almost
right away. In the "New" sub of the class a thread is created and started to
send the command data, this thread exits once it is done. So, the question
is, will the GC detect that the object is no longer in use when the thread
exits and dispose of it or is it "disposable" as soon as the object goes out
of scope?
The class "Trigger" is like this:
Public Class Trigger
Public Sub New(byval strAddress as string, byval strCommand as string)
mThread = new Thread(addressof SendCommand)
mThread.Start()
End Sub
Private Sub SendCommand()
... Do work here
End Sub
... other class methods etc
End Class
And the is like:
Public Sub VM_Send(byval strAddress as string, byval strData as string)
Dim oCommand as new Trigger(strAddress,strData)
End Sub
Thanks,
Sid.

I'm sure someone will correct me if I'm wrong - but, I believe that
the object will not be available for collection until the thread has
completed...

 

[Chris Mullins [MVP - C#]]

In your example below, as long as the thread you started is still around,
the instance of your class will have a GC root (a thread is considered to be
a root).
This means your class, and everything it refers to (member variables, etc)
will also be rooted.

If you changed "Private Sub SendCommand()" to "Private Shared Sub
SendCommand()" then your class would NOT be rooted, and your class would be
eligible for collection. This is because the shared method doesn't provide a
root to the instance of the class.

Now, I personally am not really a fan of the pattern you're using. I would
prefer a small state class "SendCommandArguments", that has all of the
information that you need to send (remote IP Address, data, credentials,
etc). Once you have this state class, pass it as an argument into the
thread, using the Paramaterized version of the Thread constructor.

Passing the state in, and making the thread method statless (i.e. doesn't
use state from any external sources) will elimiante a number of concerns
you'll bump into regarding concurrency, locking, and synchronization. This
is a much better pattern to follow, as many problems will just disappear.

I'm also not a man of creating your own threads for this. I would prefer to
see you post something to the Thread Pool, or to use Async I/O. A custom
thread will work, but there always seem to be more issues arising from this
that there should be. For example, what happens if your thread throws an
exception, and you forget to handle it? Kaboom - no more process. What if
your thread stalls for some reason? Now you app won't shutdown cleanly.

For those new to threading, the threadpool is usually the best answer...

 

[Sid Price]

I'm sure someone will correct me if I'm wrong - but, I believe that
the object will not be available for collection until the thread has
completed...

Hi Tom,
That is my wish, the alternative would mean the extra complication of
managing the objects with another class, knowing when the thread exited, and
then disposing of the object.
Sid.

 

[Sid Price]

Chris,
Thank you for this "mini-lesson", I plan to update my design to use the
state class and Thread Pool approach. It seems that the Thread Pool is
absolutely designed for this application,
Sid.

 

[Chris Mullins [MVP - C#]]

Hi Sid,

Glad to be of help. Good luck getting it all to work right.....

 

[Sid Price]

Chris,
I made the updates and everything appears to be working as required, thanks,
Sid.