VB.NET Thread Garbage Collection

  • Thread starter Thread starter Matt
  • Start date Start date
M

Matt

Hey guys, I'm attempting to create an event scheduler though VB.Net
2005 using threads.
The basic idea is that I can have up to 10 threads going at any given
time. Once a thread finishes I need to be able to "recycle" it so I
can use it again when necessary. Since there is no way to
"reinitialize" a thread I devised this method.

Thread1 = New System.Threading.Thread(AddressOf Task1.ExecuteShell)

If (Thread1.IsAlive = False) Then
If (ResetFlag1 = True) Then
Thread1 = Nothing
GC.Collect()
Thread1 = New System.Threading.Thread(AddressOf
Task1.ExecuteShell)
End If
Task1.EventID = "1"
Task1.TimerValue = Me.TimerBox.Text
Thread1.Start()
ResetFlag1 = True
End if

Basically what happens is that once the thread is used I set it to
Nothing, do a GC.Collect and reset the thread to a new thread. Now my
question here is will this eventually blow up because I keep creating
new instances of the thread object? Or will the garbage collection I
have implimented take care of it?

I'm not using a "threadqueue" because I need to have direct control
over the threads. Any help you could give me would be great
 
Matt said:
Hey guys, I'm attempting to create an event scheduler though VB.Net
2005 using threads.
The basic idea is that I can have up to 10 threads going at any given
time. Once a thread finishes I need to be able to "recycle" it so I
can use it again when necessary. Since there is no way to
"reinitialize" a thread I devised this method.

Thread1 = New System.Threading.Thread(AddressOf Task1.ExecuteShell)

If (Thread1.IsAlive = False) Then
If (ResetFlag1 = True) Then
Thread1 = Nothing
GC.Collect()
Thread1 = New System.Threading.Thread(AddressOf
Task1.ExecuteShell)
End If
Task1.EventID = "1"
Task1.TimerValue = Me.TimerBox.Text
Thread1.Start()
ResetFlag1 = True
End if

Basically what happens is that once the thread is used I set it to
Nothing, do a GC.Collect and reset the thread to a new thread. Now my
question here is will this eventually blow up because I keep creating
new instances of the thread object? Or will the garbage collection I
have implimented take care of it?

I'm not using a "threadqueue" because I need to have direct control
over the threads. Any help you could give me would be great
Click to expand...

You should not blow up and you should not call GC.Collect. The garbage
collector will handle cleaning up your old threads on its own time frame.

Chris
 
Matt,

Why do you need direct control over the threads? The reason I'm asking
is because there might be a better solution.

Brian
 
Brian,

Basically what we are doing is creating an event scheduler using
threads in the form of a service. Each thread will spawn off an XLNT
shell that will execute a job. I need to be able to halt a job if I
need to, change the priority, and to check to see if the XLNT shell is
still responding. Because of this it's my understanding that I need to
have direct control over the threads. Everything I have read about the
threadqueue which is the other way I thought about handling it,
indicates that I wont have this type of control.

Chris,

So even though this program will potentially be running for months and
months without restarting, the GC should be automatic?
 
Matt said:
Brian,

Basically what we are doing is creating an event scheduler using
threads in the form of a service. Each thread will spawn off an XLNT
shell that will execute a job. I need to be able to halt a job if I
need to, change the priority, and to check to see if the XLNT shell is
still responding. Because of this it's my understanding that I need to
have direct control over the threads. Everything I have read about the
threadqueue which is the other way I thought about handling it,
indicates that I wont have this type of control.

Chris,

So even though this program will potentially be running for months and
months without restarting, the GC should be automatic?
Click to expand...

Yes. The developer should never have to deal the GC.

Chris
 
Matt,

Yeah, I think you're taking the right approach. I believe you're
talking about the ThreadPool when you say "threadqueue". The
ThreadPool is really intended for work items that run quickly. I
suspect your XLNT jobs do not fall into that category. Also, you won't
be able to easily terminate a work item in the ThreadPool whereas you
can always use Thread.Abort as a last resort if running the job in a
single thread. Though, I recommend avoiding Thread.Abort if at all
possible.

Brian
 
Yes, "threadpool" sorry I'm new to .net :-)

As far as the Thread.Abort function we will only be using that once in
a blue moon. But we need to have the option.

Thanks again guys for your confirmations!

Cheers!
 
Back
Top