Question

Below is a simplified version of the code I’m having trouble with. When I run this in a console application, it works as expected. All queries are run in parallel and Task.WaitAll() returns when they are all complete.

However, when this code runs in a web application, the request just hangs. When I attach a debugger and break all, it shows that execution is wait on Task.WaitAll(). And the first task has completed, but the others never finish.

I can’t figure out why it hangs when running in ASP.NET, but works fine in a console application.

public Foo[] DoWork(int[] values)
{
    int count = values.Length;
    Task[] tasks = new Task[count];

    for (int i = 0; i < count; i++)
    {
        tasks[i] = GetFooAsync(values[i]);
    }

    try
    {
        Task.WaitAll(tasks);
    }
    catch (AggregateException)
    {
        // Handle exceptions
    }

    return ...
}

public async Task<Foo> GetFooAsync(int value)
{
    Foo foo = null;

    Func<Foo, Task> executeCommand = async (command) =>
    {
        foo = new Foo();

        using (SqlDataReader reader = await command.ExecuteReaderAsync())
        {
            ReadFoo(reader, foo);
        }
    };

    await QueryAsync(executeCommand, value);

    return foo;
}

public async Task QueryAsync(Func<SqlCommand, Task> executeCommand, int value)
{
    using (SqlConnection connection = new SqlConnection(...))
    {
        connection.Open();

        using (SqlCommand command = connection.CreateCommand())
        {
            // Set up query...

            await executeCommand(command);

            // Log results...

            return;
        }
    }           
}

Answer 1

Rather than Task.WaitAll you need to use await Task.WhenAll.

In ASP.NET you have an actual synchronization context. This means that after all await calls you will be marshaled back to that context to execute the continuation (effectively serializing these continuations). In a console app there is no synchronization context, so all of the continuations are just sent to the thread pool. By using Task.WaitAll in the request’s context you’re blocking it, which is preventing it from being used to handle the continuations from all of the other tasks.

Also note that one of the primary benefits of async/await in an ASP app is to not block the thread pool thread that you’re using to handle the request. If you use a Task.WaitAll you’re defeating that purpose.

A side effect of making this change is that by moving from a blocking operation to an await operation exceptions will be propagated differently. Rather than throwing AggregateException it will throw one of the underlying exceptions.