Async/Await for sequential I/O bound tasks

Question

I'm working on a firmware update app and I'm trying to use Async/Await to avoid blocking the UI. The problem I'm facing is that the process of updating firmware requires a series of steps to occur in sequence (which is not asynchronous). Yet it looks like async is still the way to go when a UI is involved to avoid freezing the application. So how do we not block the UI, sequentially complete a long running series of tasks, and not eat up or waste threads?

Here's a non-async example to illustrate the problem:

public class FirmwareUpdateViewModel : ObservableObject
{
   //ctor
   public FirmwareUpdateViewModel()
   {
       // Process should start on page load
       updateFirmware();
   }

   private void updateFirmware()
   {
       //...

       DeviceHandshake();

       SendMessage(Commands.RestartDevice);

       GetFWFileData();

       WaitForDevice(timeout);

       SendMessage(PreliminaryData);

       //...
   }
}

My first attempt was to await Task.Run(() => everything:

public class FirmwareUpdateViewModel : ObservableObject
{
   //ctor
   public FirmwareUpdateViewModel()
   {
       updateFirmwareAsync();
   }

   private async void updateFirmwareAsync()
   {
       //...

       await Task.Run(() => DeviceHandshakeAsync());

       await Task.Run(() => SendMessageAsync(Commands.RestartDevice));

       //...
   }
}

The problem here besides the async void is that because of the viral nature of Async, when I await inside DeviceHandshakeAsync, plus if Task.Run() is running on it's own thread then we are wasting a ton of threads.

I next tried dropping the Task.Run(() => and just awaiting each method, but as far as I know, the sub-methods will return when they encounter an internal await and begin to run the next sub-method before the previous completes. And now I'm trying to run the firmwareUpdate method async but not awaiting the sub-methods in an attempt to keep them synchronous and fight the viral nature, but this blocks the UI:

public class FirmwareUpdateViewModel : ObservableObject
{
   //ctor
   public FirmwareUpdateViewModel()
   {
       Result = new NotifyTaskComplete<bool>(updateFirmwareAsync());
   }

   private async Task<bool> updateFirmwareAsync()
   {
       //...

       DeviceHandshake();

       SendMessage(Commands.RestartDevice);

       //...
   }
}

The problem here is obviously that without awaits we're running synchronously and on the UI thread. Nothing has "clicked" yet for me in understanding the right approach here. How do we do it right?

Edit: I realized I left out a big part of the problem...that the USB is handled by a 3rd party library that is synchronous. So I need to wrap those functions somehow to avoid blocking the UI:

public class FirmwareUpdateViewModel : ObservableObject
{
   //ctor
   public FirmwareUpdateViewModel()
   {
       // Don't block the UI with this
       updateFirmware();
   }

   private void updateFirmware()
   {
       //...
       // Run all non-blocking but sequentially
       DeviceHandshake();

       SendMessage(Commands.RestartDevice);

       GetFWFileData();

       WaitForDevice(timeout);

       SendMessage(PreliminaryData);

       //...
   }

   private void SendMessage(Command)
   {
      // Existing code, can't make async
      USBLibrary.Write(Command);

   }
}

This is why I'm so confused, because async wants to spread but I can't in between the constructor and end library.

Answer 1

Regarding how many threads are wasted. This code:

private async void updateFirmwareAsync()
{
    //...
    await Task.Run(() => DeviceHandshakeAsync());
    await Task.Run(() => SendMessageAsync(Commands.RestartDevice));
    //...
}

...most probably wastes practically zero threads. Assuming that the methods DeviceHandshakeAsync and SendMessageAsync are asynchronous, in other words assuming that they return a Task, a ThreadPool thread will be employed just for calling these methods and getting the tasks, and then will be immediately released back to the thread pool because there is nothing else for the thread to do. Now a well behaved asynchronous method when invoked doesn't block the caller, and returns an incomplete Task almost immediately. So, unless these methods are not well behaved, a ThreadPool thread will be employed for a time span measured in microseconds.

But what happens if the two methods are synchronous?

private async void updateFirmwareAsync()
{
    //...
    await Task.Run(() => DeviceHandshake());
    await Task.Run(() => SendMessage(Commands.RestartDevice));
    //...
}

This code wastes a single ThreadPool thread. Maybe the same thread, or maybe two different threads that are employed sequentially. This thread has already been created (unless your code has never used the ThreadPool before that point), so saying that the thread is wasted is an overstatement. It would be more precise to say that a single ThreadPool thread will be reserved, and so unavailable for doing other work, for the whole duration of the firmware update. If your program does heavy use of ThreadPool threads, resulting to hiccups caused by ThreadPool starvation, you can preemptively increase the pool of threads by calling the ThreadPool.SetMinThreads method during the app initialization.

Btw here are my arguments about why it's a good idea to use await Task.Run preemptively inside event handlers of UI applications.

Answer 2

Two ways to go about this, I think.

1:

private async void updateFirmwareAsync()
{
   await Task.Run(() => 
   { 
       DeviceHandshakeAsync());
       SendMessage(Commands.RestartDevice);
       GetFWFileData();
       WaitForDevice(timeout);
       SendMessage(PreliminaryData);
   });
}

So run them sequentially in a single task, or

2:

private async void updateFirmwareAsync()
{
   await Task.Run(() => DeviceHandshakeAsync())
             .ContinueWith(() => SendMessage(Commands.RestartDevice))
             .ContinueWith(() => GetFWFileData())
             .ContinueWith(() => WaitForDevice(timeout))
             .ContinueWith(() => SendMessage(PreliminaryData))
   });
}

In practice they achieve much the same, though (1) guarantees they all run in the same thread, whereas (2) means they may run in different thread, so is more like your initial multiple await idea.

Answer 3

You should chain the function ConfigureAwait:

 public async void FirmwareUpdateViewModel() {
     await updateFirmwareAsync().ConfigureAwait(false);
 }

This will let you call the task asynchronously without waiting for it to finish, which is causing the user interface to stop painting.