Threads, Tasks, async / await, Threadpool
I'm really confused about multithreading here :( I read about the C # Async / Await keywords. I often read that with this asynchronous function the code is run "non-blocking". People put code examples in two categories "IO-Bound" and "CPU -bound "- and that I shouldn't use a thread when I do io-related stuff, because that thread will just wait ..
I don't understand ... If I don't want the user to have to wait for an operation, I have to perform that operation on a different thread, right?
If I use Threadpool, an instance of the "Thread" class, delegate.BeginInvoke, or TPL - each asynchronous execution is done on a different thread. (with or without callback)
source to share
What you are missing is that not every asynchronous operation is performed on a different thread. Waiting for an I / O operation or a web service call does not require creating a thread. On Windows, this is done using the OS I / O completion ports .
What happens when you call something like Stream.ReadAsync
is that the OS will issue a read command to disk and then return to the caller. Once the disk is finished reading, you will learn about the OS kernel, which will then call your processes. Therefore, there is no need to create a new threadpool that will just sit and block.
source to share
What is meant:
Suppose you are requesting some data from a database (on another server) - you send a request and just wait for a response. Instead of having a flow block and waiting for a return, it's better to register a callback that gets called when data is returned - that's (more or less) what async / await does. It will free the thread to do other things (put it back in the pool), but as soon as your data comes back asynchronously, it will receive another thread and continue your code where you left (this is really some kind of state machine that handles this ).
If your calculation is really CPU intensive (say you are calculating prime numbers), things are different - you are not expecting some external I / O, you are doing heavy CPU work - here is the best idea to use so that your UI is not blocked.
source to share
I don't understand ... If I don't want the user to have to wait for an operation, I have to perform that operation on a different thread, right?
Not really. The operation will take a long time. When you have a single-user application, running long resources on a separate thread keeps the UI responsive. At the very least, it allows the UI to have something like a Cancel button that can accept user input and cancel processing on another thread. For some single-user applications, it makes sense to let the user keep doing other things while a long-running task completes (for example, let them work on one file while another file is being downloaded or loaded).
For web applications, you don't want to block a thread from a thread pool during a long (ish) IO, such as reading from a database or calling another web service. This is because there is a limited number of threads in the thread pool, and if they are all in use, the web server will not be able to accept additional HTTP requests.
source to share