Dlaczego ta akcja asynchroniczna zawiesza się?

Mam wielowarstwową aplikację .Net 4,5 wywołującą metodę przy użyciu nowych asynci C #await słów kluczowych, które po prostu się zawieszają i nie rozumiem, dlaczego.

Na dole mam metodę asynchroniczną, która rozszerza nasze narzędzie bazy danych OurDBConn(w zasadzie opakowanie dla bazowego DBConnectioni DBCommandobiektów):

public static async Task<T> ExecuteAsync<T>(this OurDBConn dataSource, Func<OurDBConn, T> function)
{
    string connectionString = dataSource.ConnectionString;

    // Start the SQL and pass back to the caller until finished
    T result = await Task.Run(
        () =>
        {
            // Copy the SQL connection so that we don't get two commands running at the same time on the same open connection
            using (var ds = new OurDBConn(connectionString))
            {
                return function(ds);
            }
        });

    return result;
}

Następnie mam metodę asynchroniczną średniego poziomu, która wywołuje to, aby uzyskać wolno działające sumy:

public static async Task<ResultClass> GetTotalAsync( ... )
{
    var result = await this.DBConnection.ExecuteAsync<ResultClass>(
        ds => ds.Execute("select slow running data into result"));

    return result;
}

Wreszcie mam metodę UI (akcję MVC), która działa synchronicznie:

Task<ResultClass> asyncTask = midLevelClass.GetTotalAsync(...);

// do other stuff that takes a few seconds

ResultClass slowTotal = asyncTask.Result;

Problem w tym, że na zawsze wisi na ostatniej linii. Robi to samo, gdy dzwonięasyncTask.Wait() . Jeśli uruchomię wolną metodę SQL bezpośrednio, zajmie to około 4 sekund.

Spodziewam się zachowania, kiedy to nastąpi asyncTask.Result , jeśli nie zostanie zakończone, powinno poczekać, aż nastąpi, a gdy to się stanie, powinno zwrócić wynik.

Jeśli przejdę przez debuger, instrukcja SQL kończy się i funkcja lambda kończy się, ale return result;wierszGetTotalAsync nie zostanie osiągnięta.

Masz pojęcie, co robię źle?

Jakieś sugestie, gdzie muszę to zbadać, aby to naprawić?

Czy to może być gdzieś impas, a jeśli tak, czy istnieje bezpośredni sposób, aby go znaleźć?

Tak, to jest impas. I częsty błąd z OC, więc nie czuj się źle.

Podczas pisania await foośrodowisko uruchomieniowe domyślnie planuje kontynuację funkcji w tym samym SynchronizationContext, na którym została uruchomiona metoda. Załóżmy, że w języku angielskim ExecuteAsyncdzwoniłeś z wątku interfejsu użytkownika. Twoje zapytanie działa w wątku puli wątków (ponieważ zadzwoniłeś Task.Run), ale potem czekasz na wynik. Oznacza to, że środowisko wykonawcze zaplanuje " return result;" ponowne uruchomienie linii w wątku interfejsu użytkownika, zamiast zaplanować powrót do puli wątków.

Jak więc ten impas? Wyobraź sobie, że masz ten kod:

var task = dataSource.ExecuteAsync(_ => 42);
var result = task.Result;

Tak więc pierwsza linia rozpoczyna pracę asynchroniczną. Druga linia następnie blokuje wątek interfejsu użytkownika . Więc gdy środowisko wykonawcze chce ponownie uruchomić wiersz „zwracanego wyniku” w wątku interfejsu użytkownika, nie może tego zrobić, dopóki nie Resultzakończy się. Ale oczywiście nie można podać wyniku, dopóki nie nastąpi zwrot. Impas.

Ilustruje to kluczową zasadę korzystania z TPL: gdy używasz .Resultw wątku interfejsu użytkownika (lub innym fantazyjnym kontekście synchronizacji), należy uważać, aby nic, od czego zależy zadanie, nie zostało zaplanowane w wątku interfejsu użytkownika. Albo dzieje się zło.

Więc co robisz? Opcja nr 1 to użycie czekaj wszędzie, ale jak powiedziałeś, to już nie jest opcja. Drugą dostępną opcją jest po prostu zaprzestanie używania await. Możesz przepisać swoje dwie funkcje na:

public static Task<T> ExecuteAsync<T>(this OurDBConn dataSource, Func<OurDBConn, T> function)
{
    string connectionString = dataSource.ConnectionString;

    // Start the SQL and pass back to the caller until finished
    return Task.Run(
        () =>
        {
            // Copy the SQL connection so that we don't get two commands running at the same time on the same open connection
            using (var ds = new OurDBConn(connectionString))
            {
                return function(ds);
            }
        });
}

public static Task<ResultClass> GetTotalAsync( ... )
{
    return this.DBConnection.ExecuteAsync<ResultClass>(
        ds => ds.Execute("select slow running data into result"));
}

Co za różnica? Nie ma teraz żadnego oczekiwania, więc nic nie jest niejawnie zaplanowane w wątku interfejsu użytkownika. W przypadku prostych metod, takich jak te, które mają pojedynczy zwrot, nie ma sensu wykonywać „var result = await...; return result wzorca ”; po prostu usuń modyfikator async i przekaż obiekt zadania bezpośrednio. To mniej narzutów, jeśli nic innego.

Opcja nr 3 polega na określeniu, że nie chcesz, aby oczekiwania były planowane z powrotem do wątku interfejsu użytkownika, ale po prostu planuj do puli wątków. Robisz to ConfigureAwaitmetodą, na przykład:

public static async Task<ResultClass> GetTotalAsync( ... )
{
    var resultTask = this.DBConnection.ExecuteAsync<ResultClass>(
        ds => return ds.Execute("select slow running data into result");

    return await resultTask.ConfigureAwait(false);
}

Oczekiwanie na zadanie normalnie spowoduje zaplanowanie wątku interfejsu użytkownika, jeśli jesteś na nim; oczekiwanie na wynik ContinueAwaitspowoduje zignorowanie dowolnego kontekstu, w którym się znajdujesz, i zawsze będzie planowane do puli wątków. Wadą tego jest to, że musisz posypać to wszędzie we wszystkich funkcjach, od których zależy twój wynik, ponieważ każdy brakujący .ConfigureAwaitmoże być przyczyną kolejnego impasu.

To jest klasyczny asyncscenariusz mieszanego impasu, jak opisuję na moim blogu . Jason dobrze to opisał: domyślnie „kontekst” jest zapisywany w każdym miejscu awaiti używany do kontynuowania asyncmetody. Ten „kontekst” jest aktualny, SynchronizationContextchyba że nim jest null, w którym to przypadku jest aktualny TaskScheduler. Gdy asyncmetoda próbuje kontynuować, najpierw ponownie wchodzi do przechwyconego „kontekstu” (w tym przypadku ASP.NET SynchronizationContext). ASP.NET SynchronizationContextzezwala tylko na jeden wątek w kontekście naraz, aw kontekście istnieje już wątek - wątek zablokowany Task.Result.

Istnieją dwie wskazówki, które pozwolą uniknąć tego impasu:

1. Wykorzystaj asynccałą drogę w dół. Wspomniałeś, że „nie możesz” tego zrobić, ale nie jestem pewien, dlaczego nie. ASP.NET MVC na .NET 4.5 z pewnością może obsługiwać asyncakcje i nie jest to trudna zmiana.
2. Używaj ConfigureAwait(continueOnCapturedContext: false)jak najwięcej. Zastępuje to domyślne zachowanie wznawiania w przechwyconym kontekście.

Byłem w tej samej sytuacji zakleszczenia, ale w moim przypadku wywołanie metody asynchronicznej z metody synchronizacji działa dla mnie:

private static SiteMetadataCacheItem GetCachedItem()
{
      TenantService TS = new TenantService(); // my service datacontext
      var CachedItem = Task.Run(async ()=> 
               await TS.GetTenantDataAsync(TenantIdValue)
      ).Result; // dont deadlock anymore
}

czy to dobre podejście, jakiś pomysł?

Aby dodać do zaakceptowanej odpowiedzi (za mało przedstawiciela, aby skomentować), miałem ten problem podczas blokowania używania task.Result, zdarzenie chociaż każdy awaitponiżej miał ConfigureAwait(false), jak w tym przykładzie:

public Foo GetFooSynchronous()
{
    var foo = new Foo();
    foo.Info = GetInfoAsync.Result;  // often deadlocks in ASP.NET
    return foo;
}

private async Task<string> GetInfoAsync()
{ 
    return await ExternalLibraryStringAsync().ConfigureAwait(false);
}

Problem faktycznie dotyczył kodu biblioteki zewnętrznej. Metoda biblioteki asynchronicznej próbowała kontynuować w kontekście wywoływania synchronizacji, bez względu na to, jak skonfigurowałem oczekiwanie, co doprowadziło do zakleszczenia.

Dlatego odpowiedzią było zrolowanie własnej wersji kodu biblioteki zewnętrznej ExternalLibraryStringAsync, tak aby miała pożądane właściwości kontynuacji.

Po wielu bólu i udręce znalazłem rozwiązanie ukryte w tym poście na blogu (Ctrl-f oznacza „impas”). Obraca się wokół używania task.ContinueWithzamiast gołego task.Result.

Przykład wcześniejszego zakleszczenia:

public Foo GetFooSynchronous()
{
    var foo = new Foo();
    foo.Info = GetInfoAsync.Result;  // often deadlocks in ASP.NET
    return foo;
}

private async Task<string> GetInfoAsync()
{ 
    return await ExternalLibraryStringAsync().ConfigureAwait(false);
}

Uniknij impasu w ten sposób:

public Foo GetFooSynchronous
{
    var foo = new Foo();
    GetInfoAsync()  // ContinueWith doesn't run until the task is complete
        .ContinueWith(task => foo.Info = task.Result);
    return foo;
}

private async Task<string> GetInfoAsync
{
    return await ExternalLibraryStringAsync().ConfigureAwait(false);
}

szybka odpowiedź: zmień tę linię

ResultClass slowTotal = asyncTask.Result;

do

ResultClass slowTotal = await asyncTask;

czemu? nie powinieneś używać .result do uzyskania wyniku zadań wewnątrz większości aplikacji z wyjątkiem aplikacji konsolowych, jeśli to zrobisz, twój program zawiesi się, gdy się tam dostanie

możesz również wypróbować poniższy kod, jeśli chcesz użyć .Result

ResultClass slowTotal = Task.Run(async ()=>await asyncTask).Result;