Constant loop - Thread vs Async, best practice

Question

I have some common code that i seem to use often when it comes to some of our in house applications.

public State SomeState { get; set; }
Thread thread = new Thread(ThreadProc)
thread.Start();

void ThreadProc() {
    while(isTrue){
       //Changes SomeState after ping
       //Can take up to 5 seconds to complete if service is unavailable
       PingServiceTocheckState(); 
       UpdateUI();
       Thread.Sleep(200);
    }
}

void UpdateUI() {

    if (InvokeRequired)
    {
        Invoke(new MethodInvoker(UpdateUI));
        return;
    }

    if(SomeState == State.Up){
        //set these UI values (txt.Text = ...)
    }
    ......
}

And the constant action may be updating Ui on a windows form or constantly reading from a network stream.

I feel this is probably outdated when compared to TPL and Async.

Am I correct to feel it can be better managed using Async/TPL? And if so, could someone give me an example of how i would accomplish the above using these new ideas?

*Note: I currently use async occasionally and I am trying to make it more prevalent in my coding, but I am a little lost on the best method for creating a longrunning "background thread" using async.

Edit:

I have updated my example with a little more detail relating to my current project. I have code similar to this in a UserControl. I then have a windows form which adds ~50 of these controls dynamically. Without the Thread the form basically hangs, with the thread everything runs smooth. I just figured that rather than managing the thread myself async/TPL would manage the tasks (Ping and Update) more efficiently than myself.

Answer 1

The TPL is well suited to tasks that are short in duration - as you are basically using up workers from a pool. If your operation is continuous, a dedicated thread is entirely appropriate. If, however, the PerformAction is actually blocking waiting on data coming into a queue, and only actually has anything to do very briefly and occasionally, then yes: the TPL may come back into play. But then there is a question of sequential vs concurrent programming: at the moment, in that scenario, you will be processing things sequentially. The TPL makes no such guarantees, and is intended to process things concurrently. It is of course possible to write code that uses the TPL (or just the regualar ThreadPool) to process a sequential queue, but it is a bit more complicated, and there are edge-cases and thread-races around the "is there a current worker? do I need to start one? is it me?" questions.

Answer 2

Thread, TPL, Async stand on shoulders of the same OS kernel objects and artifacts. They are just different classes that provide different functionality to you.

None of them provides you with true low level control over threading, but, for example TPL, if can, splits your task among different cores of your CPU, and finds in general best possible way of paralleling your task on multi-core modern processors, so tends to be faster and more lightweight.

So TPL is a suggested library for multi threading handling in your app, if you have and can use most updated .NET framework.