使用 C# 和 .NET，为什么运行时不会自动异步运行？

Question

This is such a basic (read noob) question regarding the .NET async/await library but I thought I'd ask it anyhow before rewriting our api's to be awaitable.

The Question

Why wouldn't the runtime simply evaluate any given thread that has a lot of idle time and automatically operate asynchronous whenever it gets to the blocking call.

Example of some routine

1. Web request to some app...
2. App starts database call...
3. Wait for response...(idle and long)
4. Receive recordset...
5. Return to client...

If I were the runtime environment, wouldn't it be wise to simply jot down that step 3 takes a while so I should use the current thread at that point, during its idle moments, to help out other routines that would normally be waiting for our current thread to be available?

Isn't it possible that at some point in the future we'll be able to toggle a flag in the app.config (or web.config) that says <system.runtime><asyncBehavior enableAsynchronousWhenIdle=true /></system.runtime> ?

Answer 1

Sure it's possible but it completely breaks the current programming model. Before when you had a blocking call you were guaranteed that no other code would run on your thread. This change now allows re-entrant calls on the same thread.

For instance consider this case:

static int _processCount;
static object _lockObj = new object();

public Response ProcessRequest(Request request) {
     lock (_lockObj) {
         _processCount++;
         var savedCount = _processCount;

         // Make long running request

         if (savedCount != _processCount)
            throw new InvalidOperationException("Is my lock broken?");
     }
}

Before we allow processing requests during the long running process this code is fine, but if we allow new requests to be processed on the thread while it is making a long running request we open up the possibility of this case.

1. Process Request A
2. Process Request A waits for the long running operation
3. The idle processing uses the thread to process Request B.
4. Request B enters the lock because locks have thread affinity
5. Request B waits for the long running operation
6. Request A returns from the long running operation and throws an exception because it's state has been corrupted.

So the code needs to be written in such a way that it is aware of the reentrancy potential. There is no way for the Framework to know if your code will break so that change will never happen.

Answer 2

.NET (nor any framework) isn't that smart. Unless you explicitly program code to run asynchronously, it has no way of knowing if any particularly code should run asynchronously. It can't look at your code and say, "Oh here's some code that runs awhile and blocking the UI thread, so I should run this in a separate thread so that the UI can update." As far as the framework is concerned--you intended it to operate that way--and it has no intelligence to override the way you coded into something more efficient.

Answer 3

Basically because both synchronous and asynchronous approaches are useful, and sometimes blocking is fine. Asynchrony isn't a silver bullet.

In the other hand, turning all synchronous code into asynchronous operations may break a lot of code base, both from the base class library (BCL) and third-party code, because asynchronous operations should synchronize access to shared resources and objects, and current synchronous code can be an actual bomb!