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.Threadin g.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]]

Re: Thread Garbage Collection

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.


"Razzie" <razzie@quickne t.nl> wrote in message
news:uZvFegTwEH A.2624@TK2MSFTN GP11.phx.gbl...[color=blue]
> Hi all,
>
> A question from someone on a website got me thinking about this, and I
> wondered if anyone could explain this.
>
> A System.Threadin g.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
>[/color]

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

Re: Thread Garbage Collection

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.

--
HTH
Stoitcho Goutsev (100) [C# MVP]


"Razzie" <razzie@quickne t.nl> wrote in message
news:uZvFegTwEH A.2624@TK2MSFTN GP11.phx.gbl...[color=blue]
> Hi all,
>
> A question from someone on a website got me thinking about this, and I
> wondered if anyone could explain this.
>
> A System.Threadin g.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
>[/color]

[Razzie]

Re: Thread Garbage Collection

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]" <willy.denoyett e@pandora.be> wrote in message
news:%23AqZ$Obw EHA.3336@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> 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.
>
>
> "Razzie" <razzie@quickne t.nl> wrote in message
> news:uZvFegTwEH A.2624@TK2MSFTN GP11.phx.gbl...[color=green]
>> Hi all,
>>
>> A question from someone on a website got me thinking about this, and I
>> wondered if anyone could explain this.
>>
>> A System.Threadin g.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
>>[/color]
>
>[/color]

[Willy Denoyette [MVP]]

Re: Thread Garbage Collection

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" <razzie@quickne t.nl> wrote in message
news:%23xFE1nbw EHA.1976@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> 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]" <willy.denoyett e@pandora.be> wrote in message
> news:%23AqZ$Obw EHA.3336@TK2MSF TNGP11.phx.gbl. ..[color=green]
>> 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.
>>
>>
>> "Razzie" <razzie@quickne t.nl> wrote in message
>> news:uZvFegTwEH A.2624@TK2MSFTN GP11.phx.gbl...[color=darkred]
>>> Hi all,
>>>
>>> A question from someone on a website got me thinking about this, and I
>>> wondered if anyone could explain this.
>>>
>>> A System.Threadin g.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
>>>[/color]
>>
>>[/color]
>
>[/color]

[Razzie]

Re: Thread Garbage Collection

Excellent explanation. Thanks Willy.

"Willy Denoyette [MVP]" <willy.denoyett e@pandora.be> wrote in message
news:esVkGzdwEH A.3096@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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" <razzie@quickne t.nl> wrote in message
> news:%23xFE1nbw EHA.1976@TK2MSF TNGP09.phx.gbl. ..[color=green]
>> 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]" <willy.denoyett e@pandora.be> wrote in message
>> news:%23AqZ$Obw EHA.3336@TK2MSF TNGP11.phx.gbl. ..[color=darkred]
>>> 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.
>>>
>>>
>>> "Razzie" <razzie@quickne t.nl> wrote in message
>>> news:uZvFegTwEH A.2624@TK2MSFTN GP11.phx.gbl...
>>>> Hi all,
>>>>
>>>> A question from someone on a website got me thinking about this, and I
>>>> wondered if anyone could explain this.
>>>>
>>>> A System.Threadin g.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
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]