C# Thread Management for Background-Threads

Question

Today I got a Problem with a Deadlock in a App I developed. In particular I am stopping a Window which started a Thread in the Background.

Problem? On Closing of the Window the Window closed, but the Process was still alive in the Background. I thought about if the Thread itself blocks, but as a Background-declared Thread it should normaly shut down anyway. But then I noticed that "Logic.DoSomething()" started it's own endless-Threads without declaring it as Background-Threads.

So why is a (non-Background) Thread in a (Background) Thread blocking the Process? Shouldn't it shutdown because it's "Parent" runs as Background-Thread? And if not, why doesn't block the Parent-Thread itself?

public partial class MainWindow : Window
{
    private Thread TheThread { get; set; }

    public MainWindow()
    {
        InitializeComponent();

        Loaded += MainWindow_Loaded;
        Closed += MainWindow_Closed;
    }

    private void MainWindow_Loaded(object sender, EventArgs e)
    {
        // Create the (background-)thread and start it
        TheThread = new Thread(() => Logic.DoSomething());
        TheThread.IsBackground = true;
        TheThread.Start();
    }

    private void MainWindow_Closed(object sender, EventArgs e)
    {
        // Close Thread if existent.
        TheThread.Abort("Window was closed");
        TheThread.Join(500);        
    }
}

PS: Please note, that I don't use a Worker-Object because I handle the Abort-Exception in the Thread normaly.

Edit: It is a theoretical Question for a Windows Presentation Foundation-Project (WPF) and not for an Windows Forms Project. Besides of that the Basic-Question was NOT how to Start and Stop a Thread using e.g. CancellationToken. It was a Question why a Thread made by a Process doesn't kill the Process it called or is gettin stuck in the Join. Hope this is clear enough.

Answer 1

Instead of calling Abort on the thread, which is never a good idea, communicate with the thread and indicate it should stop. Then wait for the thread to stop. A good means of communicating things like this are wait handles. In the following example I'll use a ManualResetEvent:

public partial class MainWindow : Window
{
    private ManualResetEvent theThreadShouldStop;
    private Thread TheThread { get; set; }

    public MainWindow()
    {
        InitializeComponent();

        // ??? This should be set through designer!!
        Loaded += MainWindow_Loaded;
        Closed += MainWindow_Closed;

        theThreadShouldStop = new ManualResetEvent(false);
    }

    private void MainWindow_Loaded(object sender, EventArgs e)
    {
        // Create the (background-)thread and start it
        TheThread = new Thread(() => Logic.DoSomething(theThreadShouldStop));
        TheThread.IsBackground = true;
        TheThread.Start();
    }

    private void MainWindow_Closed(object sender, EventArgs e)
    {
        // Close Thread if existent.
        theThreadShouldStop.Set();
        TheThread.Join();        
        theThreadShouldStop.Close();
    }
}

Now the thread method needs to be cooperative, but as I don't know what the thread method does, I'll give an example of a common scenario where the thread runs in a loop that should be cancellable:

public class Logic
{
    public void DoSomething(ManualResetEvent cancel)
    {
        while (!WantHandle.WaitOne(cancel, 1))
        {
           ... Do stuff
        }
    }
}       

Answer 2

Threads don't have "parents". There is no hierarchy. They don't know or care what thread started them. They're just threads, and the application ends when no non-background threads are running; that's all there is to it. Threads block until another thread ends when you ask them to by calling Join. They don't just do things on their own without you telling them to. They do exactly what you tell them to.