Question

Suppose I have a code as follows:

int Main()
{
    if (true)
    {
       new Thread(()=>
          {
              doSomeLengthyOperation();
          }).Start();
    }
    while (true)
    {
       //do nothing
    }
}

There are 2 threads, I'm going to call the Main thread the thread that is executing the Main() function, and the thread being new'ed up inside the "if" test as Thread A.

My question is, when does Thread A get destroyed? Will doSomeLenghtyOperation() be able to run into completion?

Since there are no references pointing at Thread A, will it be marked as a candidate for garbage collection:

  1. Immediately after the "new Thread().Start()" statement itself finishes?
  2. Immediately after the "if(true)" scope is exited?
  3. After the doSomeLengthOperation() runs to finish?
  4. Never?

All the examples I see are the Main() holding the reference, and then Main thread waiting to join with thread A before exiting. I'm curious what the lifetime of the code above is.

Thanks in advance!

Was it helpful?

Solution

The Thread object will be eligible for garbage collection as soon as it's not used any more, i.e. immediately after calling the Start method. (It will however not be collected immediately, as the garbage collector runs at specific times.)

The actual thread however is not relying on the Thread object, and will continue to run even if the Thread object is collected.

If the thread is still running when the main method exits, the application will not end until the thread completes, unless you have marked the thread to be a background thread.

OTHER TIPS

Word "thread" could mean several things here:

  • System.Threading.Thread object (created by new Thread()),
  • CLR thread (managed thread),
  • OS thread (un-managed thread).

Thread object will be candidate for GC as soon as Start() method completes, because there are no more references to it.

Managed thread will stay alive while doSomeLengthyOperation() runs.

Quoting the article by James Kovacs, Microsoft MVP:

A managed thread's lifetime is independent of the Thread object that creates it, a very good thing given that you wouldn't want the GC to terminate a thread that was still doing work simply because you lost all references to the associated Thread object. So the GC is collecting the Thread object, but not the actual managed thread.

The article also contains some helpful code samples if you want to experiment yourself.

Operating system thread, theoretically, has no one-to-one relationship with managed threads. From MSDN:

...a sophisticated host can use the CLR Hosting API to schedule many managed threads against the same operating system thread, or to move a managed thread between different operating system threads.

In practice, however, CLR thread maps directly to a Windows thread today.

when does Thread A get destroyed?

When doSomeLengthyOperation finishes.

Will doSomeLenghtyOperation() be able to run into completion

Yes, even if the main thread exists because it is not a background thread. If you set the IsBackground property to true before starting the thread whenever the main thread exists, this thread will also be stopped.

This is an excellent question! Thread will surely finish and you can try that yourself. But it can get interesting if you call GC.Collect() in the while. According to Richter's C# via CLR, it will be garbage collected.

UPDATE

I believe it will not be Garbage Collected since Thread.CurrentThread keeps it in the memory by having a reference.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top