Why does this sync wrapper over an async method work?

Question

Given:

A legacy non-async API method on an ASP.NET/WCF web service
New async internal library
New async Web API controller that should be used going forward
A "storage provider" object that only has an async interface. Its tests pass when run asynchronously, and when run synchronously outside a request context.

The option "go async all the way" is not on the table, since it would break backward compatibility.

public class Impl {
    // This works fine when used asynchronously
    public Task<Guid> SaveThingAsync(Thing thingToSave) {
        return await _storageProvider.saveAsync(thingToSave);
    }

    public Guid SaveThing(Thing thingToSave) {
        // "Obviously", this code creates a deadlock when called 
        // from within the request context
        // return SaveThingAsync(thingToSave).Result

        // Not so obviously, this also creates a deadlock
        // return SaveThingAsync(thingToSave)
        //            .ConfigureAwait(false)
        //            .GetAwaiter()
        //            .GetResult()

        // This was deadlocking, but magically stopped
        // return Task.Run(
        //        async () => await SaveThingAsync(thingToSave)
        //                      .ConfigureAwait(false)
        //               ).Result;

        // This one works
        var saveTask = Task.Run(async () => 
                            await SaveThingAsync(thingToSave)));
        var result = saveTask.ConfigureAwait(false).GetAwaiter().GetResult();
        return result;
    }

Why?

score 1 · Answer 1 · answered Apr 06 '16 at 18:24

1

Task.Run steps "outside" the request context - it just runs on the thread pool context. So, it won't deadlock because SaveThingAsync doesn't resume on the request context.

On a side note, the ConfigureAwait(false) is meaningless there, since there is no await to configure.

On another side note, "async all the way" should still be an option. WebAPI and WCF clients don't care whether the implementation they're calling is synchronous or asynchronous. Changing a WCF method implemented synchronously to a WCF method implemented asynchronously is invisible to client code.

answered Apr 06 '16 at 18:24

Stephen Cleary

437,863
77
675
810

Well, that's annoying. Yesterday I was getting TaskCancelled exception when running the first `Task.Run` example. Since our clients don't just use a direct service reference, but instead a client library generated from our interfaces, changing the SOAP interface would break everything. – Eris Apr 06 '16 at 19:36
@Eris the client can't tell as Stephen mentioned. This is not a compat problem. This is explained here: http://stackoverflow.com/a/22591516/122718 – usr Apr 06 '16 at 20:17
@Eris: The first (commented out) `Task.Run` example is really, *really* weird. It bends my brain trying to figure out what it would do. Passing around `ConfiguredTaskAwaitable` structures is not idiomatic. You should be able to use your own (asynchronous) interface in the server instead of the synchronous interface consumed by the clients - unfortunately, this would (logically) duplicate the interface description. – Stephen Cleary Apr 07 '16 at 13:19

Why does this sync wrapper over an async method work?

1 Answers1