When correctly use Task.Run and when just async-await

前端 未结 2 1060
清酒与你
清酒与你 2020-11-22 09:55

I would like to ask you on your opinion about the correct architecture when to use Task.Run. I am experiencing laggy UI in our WPF .NET 4.5 application (with Ca

相关标签:
2条回答
  • 2020-11-22 10:38

    One issue with your ContentLoader is that internally it operates sequentially. A better pattern is to parallelize the work and then sychronize at the end, so we get

    public class PageViewModel : IHandle<SomeMessage>
    {
       ...
    
       public async void Handle(SomeMessage message)
       {
          ShowLoadingAnimation();
    
          // makes UI very laggy, but still not dead
          await this.contentLoader.LoadContentAsync(); 
    
          HideLoadingAnimation();   
       }
    }
    
    public class ContentLoader 
    {
        public async Task LoadContentAsync()
        {
            var tasks = new List<Task>();
            tasks.Add(DoCpuBoundWorkAsync());
            tasks.Add(DoIoBoundWorkAsync());
            tasks.Add(DoCpuBoundWorkAsync());
            tasks.Add(DoSomeOtherWorkAsync());
    
            await Task.WhenAll(tasks).ConfigureAwait(false);
        }
    }
    

    Obviously, this doesn't work if any of the tasks require data from other earlier tasks, but should give you better overall throughput for most scenarios.

    0 讨论(0)
  • 2020-11-22 10:56

    Note the guidelines for performing work on a UI thread, collected on my blog:

    • Don't block the UI thread for more than 50ms at a time.
    • You can schedule ~100 continuations on the UI thread per second; 1000 is too much.

    There are two techniques you should use:

    1) Use ConfigureAwait(false) when you can.

    E.g., await MyAsync().ConfigureAwait(false); instead of await MyAsync();.

    ConfigureAwait(false) tells the await that you do not need to resume on the current context (in this case, "on the current context" means "on the UI thread"). However, for the rest of that async method (after the ConfigureAwait), you cannot do anything that assumes you're in the current context (e.g., update UI elements).

    For more information, see my MSDN article Best Practices in Asynchronous Programming.

    2) Use Task.Run to call CPU-bound methods.

    You should use Task.Run, but not within any code you want to be reusable (i.e., library code). So you use Task.Run to call the method, not as part of the implementation of the method.

    So purely CPU-bound work would look like this:

    // Documentation: This method is CPU-bound.
    void DoWork();
    

    Which you would call using Task.Run:

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

    Methods that are a mixture of CPU-bound and I/O-bound should have an Async signature with documentation pointing out their CPU-bound nature:

    // Documentation: This method is CPU-bound.
    Task DoWorkAsync();
    

    Which you would also call using Task.Run (since it is partially CPU-bound):

    await Task.Run(() => DoWorkAsync());
    
    0 讨论(0)
提交回复
热议问题