Comment by tigershark

tigershark Jan 27, 2019 parent

Async await is not a coroutine implementation, it’s syntactic sugar over Task and the TaskPool that behind the scenes uses normal threads. Edit: actually it tries to use a coroutine-like implementation otherwise it falls back to the thread poool.

useerup Jan 27, 2019

It does not "fall back" to thread pool. Whenever a thread pool is used, it is because you requested it, e.g. like calling Task.Run().

The async/await implementation will never fall back to thread pool by itself. Tasks are "futures", and in that sense a thread/task pool may be used in async/await when you need to run tasks in parallel. But when a thread pool is used is always under the control of the programmer.

Task is a more basic concept than threads. Tasks are about asynchronous execution, thread about parallel execution. Parallel execution is inherently asynchronous, but asynchronous execution is not parallel.

Indeed, that it the whole idea behind async/await: Enable the asynchronous model without the overhead of multiple threads.

karl_p Jan 27, 2019

That is what I thought until I wrote the benchmark(s) in the post. I was surprised that even though I never called Task.Run, things were being run on 4-10 background threads.

It does use a threadpool scheduler by default for a console app. Yes, I could override that if I wanted to.

useerup Jan 29, 2019

I believe that there is still only one thread executing your code. Now, depending on the SynchronizationContext that thread may change. If your I/O request completes on another thread, the default synch context for console apps just continue on that thread (avoids a context switch and thus more effective).

For UI threads (WPF, WinForms) it is essential that the code continues on the original thread. This the synch context used in WPF/WinForms will post the continuation on the original thread once it becomes available (thrugh the big message loop).

For ASP.NET threads, requests are processed from a thread pool. The ASP.NET synch context IIRC will schedule continuation on any ASP.NET managed thread.

So yes, you may see your code (esp. in console apps) executing on another thread after an async call, but that does not mean that .NET schedules your tasks on a thread pool. There is still only a single thread of execution at any one time, until you explicitly use a thread pool (e.g. Task.Run)

_cdho Jan 29, 2019

Yeah, I should clarify what I was saying. I wasn't calling Task.Run(), but I was doing:

    for (var i = 0; i < 1000000; i++) { 
        var unused_task_var = RunTaskAsync();
    }
    await RunMainMonitoringTaskAsync();

And I purposefully wasn't calling await on "unused_task_var". And this was doing what I wanted, running all those tasks on multiple background threads in the pool, as long as RunTaskAsync method itself yielded once early on in its function (to return control back to the for loop).

tl;dr If you call an async method and don't await on it, it will be parallelized - for a console app, at least.

Honestly, I don't find the MS docs on this to be that great. Not 100% sure I'm even doing it the right way here. Everybody says use Task.Run but that is for CPU bound tasks. I want to run a ton of IO waiting tasks.

edit: looks like I'm doing it right. See "Async Composition" @ https://blog.stephencleary.com/2012/02/async-and-await.html

tracker1 Jan 28, 2019

Nod, iirc if you read through the specifications it is definitely Threads managed by a default pool as a default implementation. Depending on your needs trying to prematurely optimize can really distort how threads are used. I've seen this in a few prior projects, but forget some of the details.

In general it works pretty well until you need more than the defaults offer, then it becomes almost an exercise in frustration.

me551ah Jan 28, 2019

This is a good article which tries to explain how .NET works under the hood. https://blog.stephencleary.com/2013/11/there-is-no-thread.ht...

int_19h Jan 27, 2019

They use whatever the current dispatcher is. The default dispatcher is the one that uses a thread pool, because that's the only thing you can do in the absence of an event loop. But the functions themselves are compiled the same, into a state machine with callbacks. That compiled code knows nothing about threads (or event loops, for that matter). It just uses the dispatcher to schedule continuations.

This item has no comments currently.

Preferences

Keyboard Shortcuts

Story Lists

Navigation

Miscellaneous