52

I have read a lot of articles and still cant get understand this part.

Consider this code :

 private async void button1_Click(object sender, EventArgs e) { await Dosomething(); } private async Task<string> Dosomething() { await Task.Run((() => "Do Work")); return "I am done"; }

First question:

When I click the button, it will Call DoSomething and await a Task that creates a Thread from the threadpool by calling Task.Run ( if I am not mistaken ) and all of this runs asynchronously. So I achieved creating a thread that does my work but doing it asynchronously? But consider that I don't need any result back, i just want the work to be done without getting any result back, is there really a need to use async/await , and if so, how?

Second question:

When running a thread asynchronously, how does that work? Is it running on the main UI but on a separate thread or is it running on a separate thread and separate is asynchronously inside that method?

Improve this question
5
  • i'm not that familiar with async/await yet, but I believe that whether or not a new thread is used is dependent on what the OS decides - i.e., you're not guaranteed execution on a new thread. Commented Sep 22, 2015 at 20:32
  • 2
    @Tim Nit: The OS will start a new thread if told to do so. Any relevant thread pooling, etc, happens in .NET itself. Commented Sep 22, 2015 at 20:33
  • @user2864740 - Thanks for the clarification :) Commented Sep 22, 2015 at 20:36
  • 1
    async/await will never create a new thread - otherwise we would all have to write the threadsafe safe code for everything after the awaited called which is exactly what async await is trying avoid. Whether the awaited method itself spawns a new thread async/await has nothing to do with, the awaited called always runs on the same thread that called it. Commented Feb 20, 2017 at 6:32
  • 1
    @markmnl - however, anyone reading your comment here should also read the discussion between you and Matias under his answer, where it is clarified that, the continuation after the await completes might be on a different thread, depending on the current SynchronizationContext. Fortunately, for a UI thread, the context does ensure returning to that UI thread. So for UI, its definitely all one thread. [I mean, if do await, but don't do Task.Run.] Commented Jun 27, 2018 at 7:59

3 Answers 3

Reset to default
33
  1. The purpose of creating Async methods is so you can Await them later. Kind of like "I'm going to put this water on to boil, finish prepping the rest of my soup ingredients, and then come back to the pot and wait for the water to finish boiling so I can make dinner." You start the water boiling, which it does asynchronously while you do other things, but eventually you have to stop and wait for it. If what you want is to "fire-and-forget" then Async and Await are not necessary.

Simplest way to do a fire and forget method in C#?

  1. Starting a new task queues that task for execution on a threadpool thread. Threads execute in the context of the process (eg. the executable that runs your application). If this is a web application running under IIS, then that thread is created in the context of the IIS worker process. That thread executes separately from the main execution thread, so it goes off and does its thing regardless of what your main execution thread is doing, and at the same time, your main execution thread moves on with its own work.
Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

Thanks for your answer. So 1 of the biggest reasons to use "await Task.Run((() => "Do Work"));" is that I want to fire off a task that does something and I want to wait for it to complete before I continue next sentence of code. Am I right here ? So will it start only 1 thread when doing "await Task.Run((() => "Do Work"));" or does it start 2 threads ?
That is correct. await means "stop execution right here until my async task finishes" and blocks the calling thread until the async thread is done. I've used this in real life to cache data coming from a web service on application start. The application would fire off 5 asynchronous calls to different services and then await for them all to return before continuing on. This allowed all calls to happen concurrently, but still block until they all completed. Regardless of whether you are using Async/Await or just Task.Run, the task is started on a separate threadpool thread.
Simplest answer to my question that I could understood, thank you very much.
@DVK await does not block the current thread. async/await as keywords have nothing to do with concurrency. await will simply check to see if the task is completed. if it is, execution proceeds. if it's not, the method returns an unfinished task to the next method up in the call stack. one of the points of async/await is NOT having to block the current thread when waiting for an asynchronous operation to complete.
@DVK I was refering to your comments where you claimed await blocks the current thread, implied that async/await have anything at all to do with threads, that await even spawns threads, etc. All of these are just factually false.
|
18

1

There's a big difference if you don't await the Task or you await it:

  • Case you don't await it: DoSomething is called but next sentence is executed while DoSomething Task hasn't been completed.

  • Case you await it: DoSomething is called and next sentence is executed once DoSomething Task has been completed.

So, the need of async/await will depend on how you want to call DoSomething: if you don't await it is like calling it the fire & forget way.

2

Is it running on the main UI but on a separate thread or is it running on a seperate thread and separate is asynchronously inside that method?

Asynchronous code sometimes means other thread (see this Q&A Asynchronous vs Multithreading - Is there a difference?). That is, either if the code is being executed in a separate thread from the UI one or it lets continue the processing of the UI thread while it gets resumed, it's nice because UI loop can still update the screen while other tasks are being done in parallel without freezing the UI.

An asynchronous method (i.e. async method) is a syntactic sugar to tell the compiler that await statements should be treated as a state machine. The C# compiler turns your async/await code into a state machine where code awaiting a Task result is executed after the code that's being awaited.

Interesting Q&As

You might want to review these other Q&As:

OP said...

[...] But does this mean that "async/await" will fire off a thread and Task.Run also fires off a thread or are they both the same thread?

Using async-await doesn't mean "I create a thread". It's just a syntactic sugar to implement continuations in an elegant way. A Task may or may not be a thread. For example, Task.FromResult(true) creates a fake task to be able to implement an async method without requirement it to create a thread:

public Task<bool> SomeAsync() { // This way, this method either decides if its code is asynchronous or // synchronous, but the caller can await it anyway! return Task.FromResult(true); }
Improve this answer

15 Comments

async/await never creates a new thread - it executes the continuation on the same thread it was called from. whether the awaitable method called executes on a new thread async await is oblivious to
@markmnl So this is what my answer says...See the part of OP said. Excepting about something you are absolutely wrong: async/await never creates a thread BUT it's not true that it always resumes on the same thread when the execution was suspended.
@MatíasFidemraizer async await never resumes on a different thread, if the awaitable method spawns a new thread and runs something in the background then returns is of no concern to the caller - the point is when it returns the caller resumes on the same thread that called it. This is the whole point of async await - the caller doesn't have wirte multi-threaded code.
@MatíasFidemraizer I see now not necessarily it depends on the current context, I stand corrected :) stackoverflow.com/questions/21838651/…
@markmnl In ASP.NET WebAPI/MVC Core, the fact that await resumes on an another thread pool thread is a big advantage, and despite of the simplicity that provides in the UI world (as you've pointed out before), any code with shared resources should be thread-safe by default because otherwise it may work fine in WPF but it can led to a complete disaster in ASP.NET WebAPI.
|
14

The type Task<TResult> requires you to return a TResult from your task. If you don't have anything to return, you can use Task instead (which, incidentally, is the base class of Task<TResult>).

But keep in mind that a task is not a thread. A task is a job to be done, while a thread is a worker. As your program runs, jobs and workers become available and unavailable. Behind the scenes, the library will assign your jobs to available workers and, because creating new workers is a costly operation, it will typically prefer to reuse the existing ones, through a thread pool.

Improve this answer

5 Comments

Thanks for your answer. But starting a new task on a worker on threadpool, will infact use a thread different from the UI thread. I really cant see any more reasons to use async/await rather than if I want to fire off a task and wait for it to complete before I complete next sentence of code. :/
@syncis and what's the problem with that?
One of the true reasons to use await is to hide all the ugly boilerplate code normally needed to marshal a result back onto a specific thread (e.g. UI thread). Awaitable tasks have a "synchronization context". If that's the default, then it'll schedule the continuation using the thread pool -- any thread will do. But, if you have a sync context associated with e.g. WPF, and you await from the UI thread, then the continuation will get dispatched back to the UI thread automatically. void button_Click(..) { UIThreadStuff(); await WorkerThreadStuffAsync(); MoreUIThreadStuff(); }
When we write await funconeAsync() or await Task.Run(funcone), then does the funcone run in the UI thread or separate thread?
@variable when you await an async method, it will run synchronously until it hits the first await. So it depends on if there is code before the first await in funconeAsync(). If there is code before the first await, then await funconeAsync() will cause funconeAsync() to run synchronously, then the method that is awaited inside funconeAsync() will run on a different thread (not UI), BUT the code inside await funconeAsync() will only run on the UI thread IF ConfigureAwait(false) is not used. await Task.Run(funcone) will cause any code inside funcone to not run on UI.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.