To find the answer, we need to start with the underlying framework of asynchronous processing.
From a design perspective, asynchronism is a publishing subscriber mode. After all, its bottom layer uses the port completion queue, which can be reflected in the three methods provided by the IO completion port kernel object.
You can have a cursory look at the signature:
This method is mainly to bind the file handle to the kernel object of IO completion port, where NumberOfConcurrentThreads represents the maximum thread limit that the completion port is allowed to run.
Look at the signature again:
The function of this function is to throw a package to the driver through the kernel object, and the driver will interact with hardware, such as files.
Look at the signature:
This method attempts to extract the IO package from the IO completion port kernel object. If not, it will wait indefinitely until it is extracted.
With the concepts of the above three methods, let's look at the structure diagram:
This picture is very concise, but only the port completion queue is drawn. In fact, there are three queues related to IO threads, namely, waiting thread queue, releasing queue and suspending queue. Next, let's interpret it a little.
When the thread t 1 calls GetQueuedCompletionStatus, if there is no task in the task queue q 1 at this time, then t 1 will be stuck and automatically enter the thread queue. When a task (which drives delivery) enters q 1 at a certain moment, the operating system will activate the task execution of t 1 and send t 1 to the release queue.
There are two roads at this time.
If t 1 is forced to stop when it encounters a Sleep or lock lock during execution, the system will send the t 1 thread to the suspended thread queue. If all sleep, NumberOfConcurrentThreads will become 0, and no one is available at this time. What should I do? We can only ask the system to apply for more threads from the thread pool to extract tasks from the q 1 queue. At some point, the activation of the thread in the thread queue has been suspended, so it returns to the released queue to continue executing the task. When the task is completed, call the GetQueuedCompletionStatus method again to wait for the thread queue.
Of course, there is a problem here. At some point, the number of threads in the waiting thread queue will temporarily exceed NumberOfConcurrentThreads, but it is not a big problem.
Is it a bit silly to say so many theories? It doesn't matter. Next, I will take a look at the source code of windbg and coreclr.
As far as my machine is concerned, the IO completion port kernel object allows at most 12 running threads by default. If you fall asleep, see if you can break through the limit of 12. Code:
As can be seen from the figure, the limit of 12 has been broken. Is it 30? You can use windbg to help confirm.
Judging from the last line, there is nothing wrong. There are actually 30 IO completion port threads.
The so-called time-consuming operations are generally a lot of serialization and complex calculations. Here I use while(true) to simulate, because all threads have not encountered a pause event, so in theory, they will not break the limit of 12. Next, I will modify the GetString () method slightly.
Compared with the time in the figure, the limit of 12 cannot be broken after 30s. After all, these threads are all running and in the release queue, which also causes the so-called embarrassing situation that the request is unresponsive.
If I understand the above, will asynchronous operations create threads? My answer to the question is that it may or may not depend on the two callback logics mentioned above.
This article is from blogs.com/huangxincheng/p/16085461.html.