Asp.net SynchronizationContext blocca HttpApplication per le continuazioni asincrone?

Question

This comment da Stephen Cleary dice questo:

AspNetSynchronizationContext è la più strana implementazione. Tratta Post come sincrono anziché asincrono e utilizza un blocco per eseguire i delegati uno alla volta.

Analogamente, the article that he wrote on synchronization contexts e collegato al fatto che suggerisce commento:

Concettualmente, il contesto di AspNetSynchronizationContext è complessa. Durante il ciclo di vita di una pagina asincrona, il contesto inizia con un solo thread dal pool di thread ASP.NET. Dopo l'avvio delle richieste asincrone, il contesto non include alcun thread. Una volta completate le richieste asincrone, i thread del pool di thread che eseguono le routine di completamento entrano nel contesto. Questi potrebbero essere gli stessi thread che hanno avviato le richieste ma più probabilmente sarebbero stati i thread liberi al momento del completamento delle operazioni.

Se più operazioni vengono completate allo stesso tempo per la stessa applicazione, AspNetSynchronizationContext si assicura che vengano eseguite una alla volta. Possono essere eseguiti su qualsiasi thread, ma quel thread avrà l'identità e la cultura della pagina originale.

scavatura riflettore sembra convalidare questo come ci vuole un blocco sul HttpApplication invocando qualsiasi callback.

Il blocco dell'oggetto dell'app sembra una cosa spaventosa. Quindi la mia prima domanda: significa che oggi tutti i completamenti asincroni per l'intera app vengono eseguiti uno alla volta, anche quelli originati da richieste separate su thread separati con HttpContexts separati? Questo non sarebbe un enorme collo di bottiglia per qualsiasi app che faccia il 100% di uso di pagine asincrone (o controller asincroni in MVC)? Se no, perché no? Cosa mi manca?

Inoltre, in .NET 4.5, sembra che ci sia un nuovo AspNetSynchronizationContext, e quello vecchio viene rinominato LegacyAspNetSynchronizationContext e utilizzati soltanto se la nuova impostazione UseTaskFriendlySynchronizationContext applicazione non è impostata. Quindi domanda n. 2: la nuova implementazione modifica questo comportamento? Altrimenti, immagino che con i nuovi completamenti di marshaling di supporto asincrono/attendi attraverso il contesto di sincronizzazione, questo tipo di collo di bottiglia verrebbe notato molto più spesso in futuro.

La risposta a this forum post (collegata da SO risposta here) suggerisce che qualcosa di fondamentalmente cambiato qui, ma voglio essere chiaro su ciò che è e quali comportamenti sono migliorati, dal momento che abbiamo una app .NET 4 MVC 3 che è quasi tutti i metodi di azione asincrona al 100% che effettuano chiamate al servizio web.

Answer 1

Lasciami rispondere alla tua prima domanda. Nella tua ipotesi non hai considerato il fatto che richieste ASP.NET separate sono elaborate da diversi oggetti HttpApplication. Gli oggetti HttpApplication sono memorizzati nel pool. Una volta richiesta una pagina, un oggetto applicazione viene richiamato dal pool e appartiene alla richiesta fino al suo completamento.Quindi, la mia risposta alla tua domanda:

tutti completamenti asincroni per l'intera applicazione eseguire uno alla volta, anche quelli che hanno avuto origine dalle richieste separate su thread separati con HttpContexts separati

è: No, non lo fanno

Le richieste separate vengono elaborate da oggetti HttpApplication separati, bloccati HttpApplication interesserà solo una singola richiesta. Il contesto di sincronizzazione è una cosa potente che aiuta gli sviluppatori a sincronizzare l'accesso alle risorse condivise (nell'ambito della richiesta). Questo è il motivo per cui tutti i callback sono eseguiti sotto lock. Il contesto di sincronizzazione è un cuore del modello di sincronizzazione basato sugli eventi.