Thread Garbage Collection

[Razzie]

Hi all,

A question from someone on a website got me thinking about this, and I
wondered if anyone could explain this.

A System.Threading.Timer object is garbage collected if it has no references
to it. But what about threads? If I start a new thread that only does 1+1,
is it garbage collected after that? If so, do all threads get garbage
collected eventually that are 'done'? And if not, why not? Are there
references to the thread that keeps it from being garbage collected?

I hope someone can shine a light on this.

Razzie

 

[Willy Denoyette [MVP]]

Managed thread objects are treated by the GC just like any other managed
object.
As long as there is a life reference it wont be GC'd, however, the native OS
thread object that is wrapped by the managed thread object is reference
counted by the CLR's thread manager.
So, even if there is no longer a reference to a managed thread object, the
underlying thread can possibly have one reference left (the executing thread
itself).
The native thread will be cleaned-up when the thread procedure terminates
(normal exit or aborted), and the ref. count turns to 0 after decrementing.

Willy.

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Razzie,

Threads are not garbage collect if they are running even if there is no
explicit reference to them. Once they finish, though, they are eligible for
GC.

 

[Razzie]

Thanks Willy. One more thing:

'the native OS thread object that is wrapped by the managed thread object'

Maybe I misunderstand, but does this mean the managed thread object has a
reference to the native OS thread? I would expect vice versa (the OS thread
controlling all subthreads as it were). I'm afraid I might miss the simple
point of the relation between the main thread, a managed thread, and
underlying threads.

 

[Willy Denoyette [MVP]]

Not really, a managed thread object wrap's a native thread object, but it
has no reference to a specific native thread object (a native thread can be
owned by more than one managed thread in .NET - a managed thread can hold
multiple OS threads, albeit not at the same time).
Internally, the CLR hold's a reference count for the native thread (if any)
in a global table, called the thread store.
When you create an instance of a Thread class, the ref count is zero
initialized, at this stage the GC is free to collect the object when there
is no longer a life reference to the object.

However, when you "start" the thread , effectively creating the OS thread
and starting the thread procedure, the internal ref count is incremented,
the OS thread's lifetime is now tied to the value of this count. When the
thread procedure returns, the ref count is decremented, triggering a
clean-up (closing the thread handle, releasing the object from the thread
store etc...) when the count reaches zero.

Willy.

 

[Razzie]

Excellent explanation. Thanks Willy.

Not really, a managed thread object wrap's a native thread object, but it
has no reference to a specific native thread object (a native thread can
be owned by more than one managed thread in .NET - a managed thread can
hold multiple OS threads, albeit not at the same time).
Internally, the CLR hold's a reference count for the native thread (if
any) in a global table, called the thread store.
When you create an instance of a Thread class, the ref count is zero
initialized, at this stage the GC is free to collect the object when there
is no longer a life reference to the object.

However, when you "start" the thread , effectively creating the OS thread
and starting the thread procedure, the internal ref count is incremented,
the OS thread's lifetime is now tied to the value of this count. When the
thread procedure returns, the ref count is decremented, triggering a
clean-up (closing the thread handle, releasing the object from the thread
store etc...) when the count reaches zero.

Willy.