Better solution for sync/async problem in desktop app?

Question

I have WinForms app where button click calls some async method of external library.

private async void button1_Click(object sender, EventArgs e)
{
    await CallLibraryAsync();
}

private static async Task CallLibraryAsync()
{
    var library = new Library();
    await library.DoSomethingAsync();
}

The library looks like this:

public class Library
{
    public async Task DoSomethingAsync()
    {
        Thread.Sleep(2000);
        await Task.Delay(1000).ConfigureAwait(false);

        // some other code
    }
}

Before any asynchronous code there is some calculation simulated by Thread.Sleep call. In that case this call will block UI thread for 2 seconds. I have no option to change the code in DoSomethingAsync.

If I want to solve blocking problem, I could call the library in Task.Run like this:

private static async Task CallLibraryAsync()
{
    var library = new Library();

    // added Task.Run
    await Task.Run(() => library.DoSomethingAsync());
}

It solves the problem, UI is not blocke anymore, but I've consumed one thread from ThreadPool. It is not good solution.

If I want to solve this problem without another thread, I can do something like this:

private static async Task CallLibraryAsync()
{
    var library = new Library();

    // added
    await YieldOnlyAsync().ConfigureAwait(false);

    await library.DoSomethingAsync();
}

// added
private static async Task YieldOnlyAsync()
{
    await Task.Yield();
}

This solution works. Task.Yield() causes that method YieldOnlyAsync() always runs asynchronously and ConfigureAwait(false) causes that next code (await library.DoSomethingAsync();) runs on some ThreadPool thread, not UI thread.

But it is quite complicated solution. Is there any simpler?

Edit:
If the library method looks like this

public class Library
{
    public async Task DoSomethingAsync()
    {
        await Task.Delay(1000).ConfigureAwait(false);
        Thread.Sleep(2000);
        await Task.Delay(1000);

        // some other code
    }
}

UI thread would not be blocked and I do not need to do anything. But that's the problem that it is some implementation detail I do not see directly because that could be in some nuget package. When I see that the UI freezes in some situations, I may find this problem (mean CPU-bound calculation before any await in async method) just after some investigation. There is no Wait() or Result, that would be easy to find, this is more problematic.

What I would like is to be prepared for that situation if possible in some simpler way. And that's why I do not want to use Task.Run whenewer I call some third-party library.

Answer 1

If I want to solve blocking problem, I could call the library in Task.Run like this:

It solves the problem, UI is not blocke anymore, but I've consumed one thread from ThreadPool. It is not good solution.

This is exactly what you want to do in a WinForms app. CPU-intensive code should be moved to a separate thread to free up the UI thread. There isn't any downside to consuming a new thread in WinForms.

Use Task.Run to move it to a different thread, and wait asynchronously from the UI thread for it to complete.

To quote the Asynchronous programming article from Microsoft:

If the work you have is CPU-bound and you care about responsiveness, use async and await, but spawn off the work on another thread with Task.Run.

Answer 2

I have no option to change the code

People say that, but you might not actually be hamstrung thus..

Here's a simple app with the same problem you face:

It's definitely pretty sleepy:

So let's whack it into ILSpy with the Reflexil plugin loaded:

We can perhaps shorten that timeout a bit.. Right click, Edit..

Make it 1ms, Right click the assembly and Save As..

That's a bit quicker!

Have a play, NOP it out etc..

Answer 3

You wrote:

If I want to solve blocking problem, I could call the library in Task.Run like this:

private static async Task CallLibraryAsync()
{
    var library = new Library();

    // added Task.Run
    await Task.Run(() => library.DoSomethingAsync());
}

It solves the problem, UI is not blocked anymore, but I've consumed one thread from ThreadPool. It is not good solution.

(emphasis added)

...and then you proceed with inventing a convoluted hack that does the same thing: offloads the invocation of the DoSomethingAsync method to the ThreadPool. So you either want to:

1. Invoke the DoSomethingAsync method without using any thread at all, or
2. Invoke the DoSomethingAsync method on a non-ThreadPool thread.

The first is impossible. You can't invoke a method without using a thread. Code runs on CPUs, not on thin air. The second can be done in many ways, with the easiest being to use the Task.Factory.StartNew method, in combination with the LongRunning flag:

await Task.Factory.StartNew(() => library.DoSomethingAsync(), default,
    TaskCreationOptions.LongRunning, TaskScheduler.Default).Unwrap();

This way you will invoke the DoSomethingAsync on a newly created thread, which will be destroyed immediately after the invocation of the method has completed. To be clear, the thread will be destroyed when the invocation completes, not when the asynchronous operation completes. Based on the DoSomethingAsync implementation that you have included in the question (the first one), the invocation will complete immediately after creating the Task.Delay(1000) task, and initiating the await of this task. There will be nothing for the thread to do after this point, so it will be recycled.

Side notes:

1. The CallLibraryAsync method violates the guideline for not exposing asynchronous wrappers for synchronous methods. Since the DoSomethingAsync method is implemented as partially synchronous and partially asynchronous, the guideline still applies IMHO.
2. If you like the idea of controlling imperatively the current context, instead of controlling it with wrappers like the Task.Run method, you could check out this question: Why was SwitchTo removed from Async CTP / Release? There are (not very many) people who like it as well, and there are libraries available that make it possible (SwitchTo - Microsoft.VisualStudio.Threading).

Answer 4

When you use async/await for I/O or CPU-bound operations, your UI thread will not blocked. In your example, you use Thread.Sleep(2000);command for simulating your CPU-bound operations but this will block your thread-pool thread not UI thread. You can use Task.Delay(2000); for simulating your I/O operations without blocking thread-pool thread.