Thread GC collection

[puggid]

I have the following code:
====================
public class Test
{
Thread thread;
ThreadStart threadStart;
int i;

public void Run()
{
threadStart = new ThreadStart(Work);
thread = new Thread(threadStart);
thread.Name = "" +(i++ );
thread.Start();
}

public void Work()
{
int i = 0;
while (i < 10)
{
Thread.Sleep(200);
Console.WriteLine(Thread.CurrentThread.Name);
}
}
}

void main(string[] args)
{
Test test = new Test();
for (int i = 0; i < 100; i++)
{
test.Run();
}
}

======================
My question is, each time Run() is called a new thread seems to be
started. Can anyone shed light onto why any existing thread running
for the "thread" member variable isn't aborted? Or does it just
restart "thread"? The thread.Name is different each time though.

 

[Marc Gravell]

Becase you are asking it to... creating a new thread and changing the
"thread" reference doesn't affect the existing thread in the least -
it is still there, running happily. Threads are top-level objects as
far as the GC is concerned; a running thread will not be collected.
The fact that you have (or haven't) got a convenient reference to this
Thread instance is irrelevant. It wouldn't even matter if "thread" was
a method-variable and didn't exist outside of Run(), and it wouldn't
matter if we set "thread = null:" after calling Start().

There are several ways of interrupting a running thread, but the best
approaches tend to involve something graceful like a (volatile) flag
somewhere; things like Suspend() and Abort() have many associated
risks.

 

[Jon Skeet [C# MVP]]

I have the following code:

My question is, each time Run() is called a new thread seems to be
started. Can anyone shed light onto why any existing thread running
for the "thread" member variable isn't aborted? Or does it just
restart "thread"? The thread.Name is different each time though.

Your code is explicitly creating a new thread and starting it - I'd be
very surprised if it *didn't* start a new thread! As for why the other
threads are aborted - you don't have to keep a reference to a new
thread in order to stop it from being aborted. Threads will only be
aborted if that happens explicitly - e.g. calling Thread.Abort or
tearing down an AppDomain.

 

[puggid]

So what does the CLR do with the previous "thread" member variables?
Is it an issue creating new thread like this, instead of a new local
(to the method) one, or using a ThreadPool?

 

[Jon Skeet [C# MVP]]

So what does the CLR do with the previous "thread" member variables?

There's only one variable involved, and its value is changed, just like
any other variable.

Is it an issue creating new thread like this, instead of a new local
(to the method) one, or using a ThreadPool?

There's no such thing as a "local" thread. Whether you should use the
thread pool or not depends on the circumstances.

 

[Ignacio Machin ( .NET/ C# MVP )]

My question is, each time Run() is called a new thread seems to be
started. Can anyone shed light onto why any existing thread running
for the "thread" member variable isn't aborted? Or does it just
restart "thread"? The thread.Name is different each time though.

You are creating a thread, but you know that.

I think that you were expectig that as your code do not hld any
reference to the previous thread it will be recicled (or aborted). The
answer is that the thread will exist as long as it's running. Which
makes a lot of sense if you think about it. Some class in the
framework (the scheduler?) will hold a reference to it.

 

[Ignacio Machin ( .NET/ C# MVP )]

So what does the CLR do with the previous "thread" member variables?
Is it an issue creating new thread like this, instead of a new local
(to the method) one, or using a ThreadPool?

When the thread ends the variables are collected in the usual way.

It works any way, IIRC creating a new thread is more costly than using
one of the thread in the pool. but I have no idea how much though.