does task create a new thread c#

Six ways to initiate tasks on another thread in .NET

Over the years, Microsoft have provided us with multiple different ways to kick off tasks on a background thread in .NET. It can be rather bewildering to decide which one you ought to use. So here’s my very quick guide to the choices available. We’ll start with the ones that have been around the longest, and move on to the newer options.

Asynchronous Delegates

Since the beginning of .NET you have been able to take any delegate and call BeginInvoke on it to run that method asynchronously. If you don’t care about when it ends, it’s actually quite simple to do. Here we’ll call a method that takes a string:

The BeginInvoke method also takes a callback parameter and some optional state. This allows us to get notification when the background task has completed. We call EndInvoke to get any return value and also to catch any exception thrown in our function. BeginInvoke also returns an IAsyncResult allowing us to check or wait for completion.

This model is called the Asynchronous Programming Model (APM). It is quite powerful, but is a fairly cumbersome programming model, and not particularly great if you want to chain asynchronous methods together as you end up with convoluted flow control over lots of callbacks, and find yourself needing to pass state around in awkward ways.

Thread Class

Another option that has been in .NET since the beginning is the Thread class. You can create a new Thread object, set up various properties such as the method to execute, thread name, and priority, and then start the thread.

This may seem like the obvious choice if you need to run something on another thread, but it is actually overkill for most scenarios.

It’s better to let .NET manage the creation of threads rather than spinning them up yourself. I only tend to use this approach if I need a dedicated thread for a single task that is running for the lifetime of my application.

The ThreadPool was introduced fairly early on in .NET (v1.1 I think) and provided an extremely simple way to request that your method be run on a thread from the thread pool. You just call QueueUserWorkItem and pass in your method and state. If there are free threads it will start immediately, otherwise it will be queued up. The disadvantage of this approach compared to the previous two is that it provides no mechanism for notification of when your task has finished. It’s up to you to report completion and catch exceptions.

This technique has now really been superseded by the Task Parallel Library (see below), which does everything the ThreadPool class can do and much more. If you’re still using it, its time to learn TPL.

BackgroundWorker Component

The BackgroundWorker component was introduced in .NET 2 and is designed to make it really easy for developers to run a task on a background thread. It covers all the basics of reporting progress, cancellation, catching exceptions, and getting you back onto the UI thread so you can update the user interface.

You put the code for your background thread into the DoWork event handler of the background worker:

and within that function you are able to report progress:

You can also check if the user has requested cancellation with the BackgroundWorker.CancellationPending flag.

The BackgroundWorker provides a RunWorkerCompleted event that you can subscribe to and get hold of the results of the background task. It makes it easy to determine if you finished successfully, were cancelled, or if an exception that was thrown. The RunWorkerCompleted and ProgressChanged events will both fire on the UI thread, eliminating any need for you to get back onto that thread yourself.

BackgroundWorker is a great choice if you are using WinForms or WPF. My only one criticism of it is that it does tend to encourage people to put business logic into the code behind of their UI. But you don't have to use BackgroundWorker like that. You can create one in your ViewModel if you are doing MVVM, or you could make your DoWork event handler simply call directly into a business object.

Task Parallel Library (TPL)

The Task Parallel Library was introduced in .NET 4 as the new preferred way to initiate background tasks. It is a powerful model, supporting chaining tasks together, executing them in parallel, waiting on one or many tasks to complete, passing cancellation tokens around, and even controlling what thread they will run on.

In its simplest form, you can kick off a background task with TPL in much the same way that you kicked off a thread with the ThreadPool .

Unlike the ThreadPool though, we get back a Task object, allowing you to wait for completion, or specify another task to be run when this one completes. The TPL is extremely powerful, but there is a lot to learn, so make sure you check out the resources below for learning more.

C# 5 async await

The async and await keywords were introduced with C# 5 and .NET 4.5 and allow you to write synchronous looking code that actually runs asynchronously. It’s not actually an alternative to the TPL; it augments it and provides an easier programming model. You can call await on any method that returns a task, or if you need to call an existing synchronous method you can do that by using the TPL to turn it into a task:

The  advantages are that this produces much easier to read code, and another really nice touch is that when you are on a UI thread and await a method, when control resumes you will be back on the UI thread again:

This model also allows you to put one try…catch block around code that is running on multiple threads, which is not possible with the other models discussed. It is also now possible to use async and await with .NET 4 using the BCL Async Nuget Package.

Here’s a slightly longer example showing a button click event handler in a Windows Forms application that calls a couple of awaitable tasks, catches exceptions whatever thread its on and updates the GUI along the way:

Obviously I can’t fully explain how to use each of these approaches in a short blog post like this, but many of these programming models are covered in depth by some of my fellow Pluralsight Authors. I’d strongly recommend picking at least one of these technologies to master (TPL with async await would be my suggestion).

Thread and ThreadPool:

• CLR Threading (Mike Woodring)  

Asynchronous Delegates:

• C# Events, Delegates and Lambdas (Dan Whalin) (Module 5)

BackgroundWorker:

• Introduction to the BackgroundWorker Component (Jeremy Clark)

Task Parallel Library:

• TPL Async (Ian Griffiths)
• Intro to Async and Parallel Programming in .NET 4 (Joe Hummel)  
• Async and Parallel Programming: Application Design (Joe Hummel)

Async and Await

• Asynchronous C# 5.0 (Jon Skeet)

Thank you for explaining all these methods! I'm always having a hard time deciding on what to use!

C# 5 async await doesn't create a new Thread. Async Await goes into the state machine and runs within the same context thread on its .next invocation. Though you can run an async-await on a new thread/task, but it itself doesn't create a new thread. Note: Every asynchronously running thing doesn't run a new Thread.

sure, this is quite an old post and the technique of awaiting a Task.Run I showed in this article is very rarely needed these days as most IO operations have Async versions you can use

So, I want this UDPClient's Send and Receive methods to run indefinitely till the lifespan of my application as there are many different forms from/to where any data will be sent/received. What method will you suggest I go with.You already explained in your article that Thread Class would be helpful in my case but one thing is I'm just starting with threads so, a few Lines of code in your explanation will be much appreciated. Like if I create a thread how will I access that thread to call those methods from a different form other than from where the Thread was actually created. Thank you.

How-To Geek

How do tasks work in c# async/background threads.

If you want to make web requests in C#, or just want to do some background processing, you'll need to use asynchronous background tasks to not block up the main thread.

Quick Links

What is async/await, what are tasks.

If you want to make web requests in C#, or just want to do some background processing, you'll need to use asynchronous background tasks to not block up the main thread. We'll discuss what they are, and how to use them.

To use Tasks, you must first understand the concept of async / await . C# tasks don't have to run asynchronously, but considering the sole purpose of them is to represent an asynchronous operation, they almost always will run async. You don't want to run operations like fetching web requests and writing to hard drives on the main thread, because it would hold up the rest of the application (including the UI) while waiting for the result.

async / await  is special syntax used to deal with asynchronous operations. If a function is marked as async , it will usually return a Task, except in cases of event handlers that return void .

Inside the async function, you can use the  await  keyword to wait for async operations to finish without blocking the whole thread. Everything that comes after the await  keyword will only run after the

 operation finishes.

public async Task FetchWebResponse(string url)

var response = await SendRequest(url)

The value being awaited must be a Task, as the two go hand in hand with each other. When you call the SendRequest()  function, it returns a Task<T> , and the program waits until that task finishes. You can think of await  as a keyword used to return or wait for the value of a task to finish.

Tasks are wrappers used to deal with asynchronous functions. They essentially represent a value that will be returned in the future. You can use the await  keyword to wait for the result, or access it directly by checking if Task.IsCompleted  and then reading the value of Task.Result .

You can create them by writing an async function with a return type of Task<T> . Then, all you have to do is return a value of type T, and .NET will interpret that as returning a Task. You can use await  inside this task to wait for async operations, which in turn return a task themselves.

You can start running a Task using Task.Run(Action action) . This will queue up the Task on the thread pool, which will run in the background on a different thread. The thread pool takes a queue of tasks, and assigns them to CPU threads for processing. Once they return, they're put into the list of completed tasks where their values can be accessed.

However, even though it's on a background thread, it's still very important to use async/await . If you make a blocking call to an API on a background thread, and don't await  it, .NET will keep that thread blocked until it completes, filling up the thread pool with useless threads doing nothing but hurting performance.

If you need to await a task from the UI thread, start it with Task.Run , then check regularly to see if the task has been completed. If it has, you can handle the value.

You can also run and await tasks inside other Tasks. For example, say you have a function inside a task, DoExpensiveCalculation() , that takes a while to execute. Rather than processing it synchronously, you can write it as a Task, and queue up a background thread at the beginning of the main task. Then, when you need the value from that calculation, you can simply await  the task, and it will yield until the task is completed, and the return value is returned.

• Blazor WASM 🔥
• ASP.NET Core Series
• GraphQL ASP.NET Core
• ASP.NET Core MVC Series
• Testing ASP.NET Core Applications
• EF Core Series
• HttpClient with ASP.NET Core
• Azure with ASP.NET Core
• ASP.NET Core Identity Series
• IdentityServer4, OAuth, OIDC Series
• Angular with ASP.NET Core Identity
• Blazor WebAssembly
• .NET Collections
• SOLID Principles in C#
• ASP.NET Core Web API Best Practices
• Top REST API Best Practices
• Angular Development Best Practices
• 10 Things You Should Avoid in Your ASP.NET Core Controllers
• C# Back to Basics
• C# Intermediate
• Design Patterns in C#
• Sorting Algorithms in C#
• Docker Series
• Angular Series
• Angular Material Series
• HTTP Series
• .NET/C# Author
• .NET/C# Editor
• Our Editors
• Leave Us a Review
• Code Maze Reviews

Select Page

Tasks vs Threads in C#

Posted by Code Maze | Updated Date Nov 7, 2022 | 0

In this article, we are going to look at the main differences between Tasks and Threads. They are both used for concurrent programming, but Tasks were later introduced with .NET Framework 4.

Let’s start with the first question that comes to mind: why do both Tasks and Threads exist in C#?

Why Were Tasks Introduced?

Before .NET Framework 4, the only way to do concurrent programming was to use the Thread class. An instance of this class represents a managed thread that the OS internally schedules. Let’s see how to create a new thread:

Here we are spawning a new thread to do a “complex” computation. When we call the Join() method, the current thread waits until the target thread terminates.

There is nothing wrong with this code, but we should be aware that spawning a thread has a cost. We should never create a new thread every time we need to execute a “task” because thread initialization and disposal are expensive activities for the OS . A web server that creates a new thread for each request would not work when the load is high.

What should we do then?

From Threads to Thread Pool Threads

Microsoft decided to introduce a thread pool implementation inside the CLR. When the application starts, the thread pool contains no threads. They are created on-demand only when the application needs them. After the thread completes, it is not destroyed, unless it remains inactive for too much time.

Instead, it returns to the thread pool in a suspended state and is awakened whenever necessary. The thread pool implementation also has some configurable parameters, like the minimum and maximum threads that can be spawned.

Let’s write the same example we have seen above, now with thread pool threads:

The ThreadPool.QueueUserWorkItem() method accepts a Thread that an available thread pool thread will later execute. The problem is that this method doesn’t return anything useful to monitor the thread status. Basically, we cannot know when the thread pool thread finishes executing the delegate.

To synchronize the thread pool thread and the current thread, we use the ManualResetEventSlim class. It is a lightweight object that works similarly to a semaphore. When we call the mres.Wait() method, the calling thread waits until the mres object receives a signal, emitted by the mres.Set() method.

However, this is not the best approach. The code is complex and hard to synchronize because it is intrinsically a fire-and-forget approach. We just know that a thread pool thread will execute the delegate we passed as the first argument. Moreover, in common with native threads, we are forced to handle exceptions inside the delegate function. 

The birth of a library that could simplify these operations was inevitable.

Finally, Tasks Came to Our Rescue

The library we are talking about is the Task Parallel Library (or TPL), which includes the Task class. A Task is an abstraction that allows us to easily use the thread pool or native threads without the complexity we saw previously. By default, each Task is executed in a background thread that belongs to the thread pool .

Once again, let’s rewrite the code above with tasks:

To create a task, we mainly have 2 options, better explained here . In this case, we use the Task.Run() method, which returns an object of type Task<double> . This object has a Result property containing the result of the task, if already available.

If the result is unavailable, then the current thread synchronously waits until available. Not only is the code clearer, but also optimized because we are now using thread pool threads.

We can decide to execute a task on a new non-thread pool thread. This turns out to be useful when we know that the task will run for a long time. In this case, a thread pool thread isn’t suitable to run this task because it would stay busy too long, stealing resources from other tasks. Instead, we want to have a thread dedicated to that task. Check out our article on Long-Running Tasks in a Monolith ASP.NET Core Application to learn more.

Tasks have much more to offer compared to threads, let’s explore them!

Tasks vs Threads: The Main Differences

So far, we have seen the theoretical aspects of tasks, but it’s time to see them in action. The problem we need to solve today consists of minimizing the building time of a car. A car is made of many components that we can build in parallel. We will solve the problem using threads and using tasks, separately. 

Let’s start with a base class containing the methods we need to build a car:

A car needs several components: a body, an engine, and suspensions. We will build them in threads/tasks, but following 2 rules:

• The painting starts after the body is ready
• The testing phase starts when all components are ready

Let’s start with the body!

Tasks Return Results

Now, let’s see how to use threads to build the car’s body:

One detail we have not underlined before is that threads do not have a return value after the execution.

Tasks can return a result, that we can access with the Result property:

var bodyTask = Task.Run(() => carBuilding.BuildBody(100, 5, 2));

This is very convenient because we don’t have to declare an external variable.

Once the body is ready, we have to paint it. How do we do that?

Tasks Are Chainable

Let’s start the thread for painting the body when it is ready:

With threads, dependencies between threads don’t stand out, but we have to find them by reading the code. Moreover, recognizing dependent threads is more difficult when many threads are involved in the “dependency graph”. With tasks, this is not a problem because they are chainable:

With the ContinueWith() method, when the bodyTask terminates, the paintingTask automatically starts. ContinueWith() makes a dependency between 2 tasks clear and well-defined .

The ContinueWith() method accepts a delegate and, optionally, a TaskContinuationOptions . This second argument specifies the conditions under which the continuation task starts.

For example, if we wanted to start the painting process just in case the bodyTask didn’t throw any exceptions:

Managing Tasks vs Threads

After the car’s body, we need suspensions too. We decide to build them concurrently, each one in a separate thread:

The first problem is that we are spawning several threads, but we have also seen how to fix this performance issue with thread pool threads. However, this time we need a thread-safe collection to store the built suspensions.

With tasks, the ConcurrentBag is unnecessary:

The Task.WhenAll() method returns a task that will complete when all the tasks in the suspensionTasks list have been completed. This is very useful when we have to coordinate many antecedent tasks with a continuation task. In this case, either we chain a ContinueWith() to the task returned by the WhenAll() method.

Optionally, we use the Task . Factory. ContinueWhenAll() method:

Task.Factory.ContinueWhenAll(suspensionTasks, tasks => tasks.ToList());

What about exceptions?

Tasks Propagate Exceptions

In the final phase of the car-building process, we need to test if the components previously built are compatible. This step could generate an exception we want to catch and rethrow outside the thread. However, threads do not propagate exceptions. One possibility is to handle the exception in the thread by saving the caught exception:

The thrownException variable is null when no exception occurred in the thread. Once the thread terminates, we just have to check if thrownException is not null. If an exception occurred, we rethrow the saved exception.

Unlike threads, tasks do propagate exceptions, which are wrapped in an AggregateException . To retrieve the wrapped exceptions we can inspect the InnerExceptions property:

In this case, we just rethrow the first inner exception, but we can also handle it with the AggregateException.Handle() method.

Tasks seem to beat threads in every respect, is it true?

Are Tasks Always the Right Choice Over Threads?

Regarding tasks, we have explored just the tip of the iceberg. Tasks are optimized to work on thread pool threads, and each of them has its local queue. We have not talked about child tasks, that leverage the data locality of the local queues. The Task class also contains heuristics to be able to find the best way to execute our tasks.

When it comes to ease of use, tasks win hands down. Besides the examples above, the Task APIs fully support CancellationToken s, which are essential to stopping a task early. On this subject, threads only provide Abort() / Interrupt() methods, whose generated exceptions are quite annoying to handle.

Task is also the core of asynchronous programming, as we have explained in this and this other article .

So, should we forget about the Thread class? No, of course. The point is that the use cases where we should use threads instead of tasks are very few .

When to Use Threads Over Tasks

We have to use a Thread when we need a foreground execution of some code. Tasks always run on background threads, which do not block the application from exiting.

The choice of a native Thread is justified when the thread has a particular priority. It is possible to indirectly change a task priority by specifying a custom scheduler, during creation. Implementing a Task scheduler isn’t always worth it, that’s why spawning a new thread is usually the best option.

A Thread has a stable identity associated. This is useful while debugging because we can know the identity of the thread that will execute our code. Tasks run on thread pool threads by default, but we have seen that this is configurable. Long-running tasks have their dedicated threads, so, even in this case, we should prefer tasks.

We can safely say that tasks are superior to threads from almost every point of view. Tasks should be our primary choice when we need concurrent/parallel programming. After all, a task is an abstraction that allows us to easily use and manage threads.

Join our 20k+ community of experts and learn about our Top 16 Web API Best Practices .

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Using threads and threading

• 13 contributors

With .NET, you can write applications that perform multiple operations at the same time. Operations with the potential of holding up other operations can execute on separate threads, a process known as multithreading or free threading .

Applications that use multithreading are more responsive to user input because the user interface stays active as processor-intensive tasks execute on separate threads. Multithreading is also useful when you create scalable applications because you can add threads as the workload increases.

If you need more control over the behavior of the application's threads, you can manage the threads yourself. However, multithreaded programming is greatly simplified with the System.Threading.Tasks.Parallel and System.Threading.Tasks.Task classes, Parallel LINQ (PLINQ) , concurrent collection classes in the System.Collections.Concurrent namespace, and a programming model that's based on the concept of tasks rather than threads. For more information, see Parallel Programming and Task Parallel Library (TPL) .

How to: Create and start a new thread

You create a new thread by creating a new instance of the System.Threading.Thread class. You provide the name of the method that you want to execute on the new thread to the constructor. To start a created thread, call the Thread.Start method. For more information and examples, see the Creating threads and passing data at start time article and the Thread API reference.

How to: Stop a thread

To terminate the execution of a thread, use the System.Threading.CancellationToken . It provides a unified way to stop threads cooperatively. For more information, see Cancellation in managed threads .

Sometimes it's not possible to stop a thread cooperatively because it runs third-party code not designed for cooperative cancellation. In this case, you might want to terminate its execution forcibly. To terminate the execution of a thread forcibly, in .NET Framework you can use the Thread.Abort method. That method raises a ThreadAbortException on the thread on which it's invoked. For more information, see Destroying threads . The Thread.Abort method isn't supported in .NET Core. If you need to terminate the execution of third-party code forcibly in .NET Core, run it in the separate process and use the Process.Kill method.

The System.Threading.CancellationToken isn't available before .NET Framework 4. To stop a thread in older .NET Framework versions, use the thread synchronization techniques to implement the cooperative cancellation manually. For example, you can create the volatile boolean field shouldStop and use it to request the code executed by the thread to stop. For more information, see volatile in C# Reference and System.Threading.Volatile .

Use the Thread.Join method to make the calling thread wait for the termination of the thread being stopped.

How to: Pause or interrupt a thread

You use the Thread.Sleep method to pause the current thread for a specified amount of time. You can interrupt a blocked thread by calling the Thread.Interrupt method. For more information, see Pausing and interrupting threads .

Thread properties

The following table presents some of the Thread properties:

• System.Threading.Thread
• Threads and Threading
• Parallel Programming

.NET feedback

The .NET documentation is open source. Provide feedback here.

Submit and view feedback for

Additional resources

• .NET Framework
• C# Data Types
• C# Keywords
• C# Decision Making
• C# Delegates
• C# Constructors
• C# ArrayList
• C# Indexers
• C# Interface
• C# Multithreading
• C# Exception

• Explore Our Geeks Community
• Lifecycle and States of a Thread in C#
• Main Thread in C#
• Types of Threads in C#
• C# | Thread(ThreadStart) Constructor
• Suspending the current thread for the specified amount of time in C#
• How to Terminate a Thread in C#
• Thread Class in C#
• How to check whether a thread is alive or not in C#
• Joining Threads in C#
• How to check whether a thread is a background thread or not in C#
• Thread.CurrentThread Property in C#
• C# | How to check current state of a thread
• C# | Getting the unique identifier for the current managed thread
• Naming a thread and fetching name of current thread in C#
• C# | Check if a thread belongs to managed thread pool or not
• C# | Thread Priority in Multithreading
• C# | Thread(ParameterizedThreadStart) Constructor
• How to set the appearance of RadioButton in C#?

How to create Threads in C#

In C#, you can create threads using the System.Threading namespace. Here is an example code snippet:

In this example, we create a new thread using the Thread class and passing in a delegate to the Worker method. We then start the thread using the Start method.

In the Main method, we do some work in the main thread and then wait for the worker thread to finish using the Join method.

In the Worker method, we do some work in the worker thread.

Note that when creating threads, you should always make sure to properly synchronize access to shared data between threads to avoid race conditions and other synchronization issues.

In C#, a multi-threading system is built upon the Thread class, which encapsulates the execution of threads. This class contains several methods and properties which helps in managing and creating threads and this class is defined under System.Threading namespace. The System.Threading namespace provides classes and interfaces that are used in multi-thread programming. Some commonly used classes in this namespace are :  

.math-table { border-collapse: collapse; width: 100%; } .math-table td { border: 1px solid #5fb962; text-align: left !important; padding: 8px; } .math-table th { border: 1px solid #5fb962; padding: 8px; } .math-table tr>th{ background-color: #c6ebd9; vertical-align: middle; } .math-table tr:nth-child(odd) { background-color: #ffffff; } 

Steps to create a thread in a C# Program:

• First of all import System.Threading namespace, it plays an important role in creating a thread in your program as you have no need to write the fully qualified name of class everytime.
• Now, create and initialize the thread object in your main method.
• Or You can also use ThreadStart constructor for initializing a new instance.
• Now you can call your thread object.

Below programs illustrate the practical implementations of above steps: Example 1:  

Explanation: In the above example, we have a class named as ExThread that contain a non-static method named as mythread1() . So we create an instance, i.e. obj of ExThread class and refer it in the constructor of ThreadStart class as given in this statement Thread a = new Thread(new ThreadStart(obj.mythread1));. Using Thread a = new Thread(new ThreadStart(obj.mythread1)); statement we will create a thread named as thr and initialize the work of this thread. By using thr.Start(); statement. Example 2:  

Explanation: In the above example, we have a class named as ExThread and contain two static methods named as thread1() and thread2() . So we do not need to create an instance of ExThread class. Here we call these methods using a class name, like ExThread.thread1, ExThread.thread2. By using Thread a = new Thread(ExThread.thread1); statement we create and initialize the work of thread a , similarly for thread b . By using a.Start(); and b.Start(); statements, a and b threads scheduled for execution. Note: The output of these programs may vary due to context switching.

Please Login to comment...

• CSharp Multithreading

Please write us at contrib[email protected] to report any issue with the above content

Improve your Coding Skills with Practice

• TECHNOLOGIES
• An Interview Question

• Task vs Thread differences in C#

• Ajeet Singh
• Nov 30, 2018

In this blog we will learn Task Vs Thread differences in C#. Difference between Task and Thread. Task in C#, Thread in C#.

Task vs Thread Differences in C#

• If system has multiple tasks then it make use of the CLR thread pool internally, and so do not have the overhead associated with creating a dedicated thread using the Thread. Also reduce the context switching time among multiple threads.
• Task can return a result. There is no direct mechanism to return the result from thread.
• Wait on a set of tasks, without a signaling construct.
• We can chain tasks together to execute one after the other.
• Establish a parent/child relationship when one task is started from another task.
• Child task exception can propagate to parent task.
• Task support cancellation through the use of cancellation tokens.
• Asynchronous implementation is easy in task, using’ async’ and ‘await’ keywords.

7 Ways to create tasks in .NET C#

If you are programming in C# (.NET) and you are in the situation of having to create and execute a Task in a new thread , you can proceed in many different ways.

First you add the following using directive:

 using System.Threading.Tasks;

Use one of the following methods:

• Classic Method
• Using Delegate
• Using Action
• Using Lambda with no method
• Using Lambda with a method
• Using Run  (.NET 4.5)
• Using FromResult  (.NET 4.5)

Remember that it is not possible to start a Task that has already been executed.

In this case (if you have to re-execute the same Task) you will have to re-initialize the Task before you can re-execute it.