By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,566 Members | 1,783 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,566 IT Pros & Developers. It's quick & easy.

Thread GC collection

P: n/a
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.
Jul 2 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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.
Jul 2 '08 #2

P: n/a
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?
Jul 2 '08 #3

P: n/a
<pu****@googlemail.comwrote:
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.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com
Jul 2 '08 #4

P: n/a
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.
Jul 2 '08 #5

P: n/a
On Jul 2, 9:19*am, pug...@googlemail.com wrote:
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.
Jul 2 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.