Asp.net SynchronizationContext 锁定 HttpApplication 以进行异步延续？

Question

This comment通过 Stephen Cleary说的是:

AspNetSynchronizationContext is the strangest implementation. It treats Post as synchronous rather than asynchronous and uses a lock to execute its delegates one at a time.

同样，the article that he wrote on synchronization contexts并链接到该评论建议:

Conceptually, the context of AspNetSynchronizationContext is complex. During the lifetime of an asynchronous page, the context starts with just one thread from the ASP.NET thread pool. After the asynchronous requests have started, the context doesn’t include any threads. As the asynchronous requests complete, the thread pool threads executing their completion routines enter the context. These may be the same threads that initiated the requests but more likely would be whatever threads happen to be free at the time the operations complete.

If multiple operations complete at once for the same application, AspNetSynchronizationContext will ensure that they execute one at a time. They may execute on any thread, but that thread will have the identity and culture of the original page.

在反射器中挖掘似乎验证了这一点，因为它在调用任何回调时都会锁定 HttpApplication。

锁定应用程序对象似乎是一件可怕的事情。所以我的第一个问题:这是否意味着今天整个应用程序的所有异步完成一次执行一个，甚至是源自具有单独 HttpContext 的单独线程上的单独请求的异步完成？对于任何 100% 使用异步页面(或 MVC 中的异步 Controller )的应用程序来说，这不是一个巨大的瓶颈吗？如果没有，为什么不呢？我错过了什么？

此外，在 .NET 4.5 中，似乎有一个新的 AspNetSynchronizationContext，旧的已重命名为 LegacyAspNetSynchronizationContext，并且仅在新应用设置 时使用未设置 UseTaskFriendlySynchronizationContext。那么问题#2:新的实现会改变这种行为吗？否则，我想随着新的 async/await 支持通过同步上下文编码(marshal)完成，这种瓶颈将更加频繁地被注意到。

this forum post的答案(链接自 SO 答案 here )表明这里发生了根本性的变化，但我想清楚这是什么以及哪些行为得到了改进，因为我们有一个 .NET 4 MVC 3 应用程序，它几乎是 100% 异步操作调用 Web 服务的方法。

Answer 1

我来回答你的第一个问题。在您的假设中，您没有考虑单独的 ASP.NET 请求由不同的 HttpApplication 对象处理的事实。 HttpApplication 对象存储在池中。一旦您请求一个页面，就会从池中检索一个应用程序对象并属于该请求，直到请求完成为止。那么，我对你的问题的回答:

all asynchronous completions for the entire app execute one at a time, even ones that originated from separate requests on separate threads with separate HttpContexts

是:不，他们没有

单独的请求由单独的 HttpApplication 对象处理，锁定的 HttpApplication 只会影响单个请求。同步上下文是一个强大的东西，可以帮助开发人员同步对共享(在请求范围内)资源的访问。这就是为什么所有回调都在锁定下执行。同步上下文是基于事件的同步模式的核心。