为什么使用Task.ContinueWith会伤害我的程序的响应能力？

Question

We have a video player written in WPF with a scroll bar. When the scroll bar is dragged right-left the CurrentFrameTime is updated and triggers UpdateFrames which, in turn, grabs the frame and shows it. That works fine.

But, sometimes grabbing the frame can take time (because of the disk for example) and though CurrentFrameTime value can be already changed, the UpdateFrames can be "stuck" and still be waiting for previous frame in ...GetAsync().Result . What is decided to do is to move Dispatcher.BeginInvoke into ContinueWith block. Now, each time the CurrentFrameTime is changed, the previous operation will be canceled(we don't need to show the frame if frame time was already changed) and an up-to-date frame should be shown. But, for some reason because of this change the application became slower. When I drag the scroll it can take a few seconds before the image is updated.

What could happened that moving the code into ContinueWith has slowed down the video player?

MainApplication without ContinueWith

_threadUpdateUI = new Thread(new ThreadStart(UpdateFrames));

public long CurrentFrameTime
{
  get{...}
  set
  {
     ...
     _fetchFrame.Set();
  }
}

void UpdateFrames()
{
    while(run)
    {
       _fetchFrame.WaitOne();

       var frame = Cache.Default.GetAsync(CurrentFrameTime)
                                .Result;
       Dispatcher.BeginInvoke(new Action(() => ShowFrame(frame.Time, frame.Image)));           
    }
}

Cache

public Task<VideoFrame> GetAsync(long frameTime)
{
    //this i used when cache is disabled
    if (GrabSynchronously)
    {
        var tcs = new TaskCompletionSource<VideoFrame>();  
        //reading from file      
        var frame2 = FrameProvider.Instance.GetFrame(frameTime);                
        tcs.SetResult(frame2);
        return tcs.Task;
    }

    ...
}

MainApplication WITH ContinueWith

void ShowFrames()
{
   while(run)
   {
      _fetchFrame.WaitOne();

      _previousFrameCancellationToken.Cancel();
      _previousFrameCancellationToken = new CancellationTokenSource();

      Cache.Default.GetAsync(CurrentFrameTime).ContinueWith((task) =>
      {
          var frameTime = task.Result.Time;
          var frameImage = task.Result.Image
          Dispatcher.BeginInvoke(new Action(() => ShowFrame(frameTime, frameImage)));
      }, _previousFrameCancellationToken.Token);    
   }
}

df

Answer 1

In your old way your UpdateFrames loop would block every .Result call. This made your loop self metering, only allowing one request "in flight" at a time even if _fetchFrame got .Set() called many times while it was waiting for .Result to finish.

In your new way every call to _fetchFrame.Set() triggers another task to start up and be "in flight" (assuming GrabSynchronously is false) even if it never gets used. This is flooding your system with requests and is causing your slowdown.

One possible solution is to put another semaphore of some type to limit the number of concurrent requests for frames you can handle.

Semaphore _frameIsProcessing = new Semaphore(5, 5); //Allows for up to 5 frames to be requested at once before it starts blocking requests.

private void ShowFrames()
{
    while (run)
    {
        _fetchFrame.WaitOne();

        _previousFrameCancellationToken.Cancel();
        _previousFrameCancellationToken = new CancellationTokenSource();

        _frameIsProcessing.WaitOne();
        Cache.Default.GetAsync(CurrentFrameTime).ContinueWith((task) =>
        {
            _frameIsProcessing.Release();

            if(_previousFrameCancellationToken.IsCancellationRequested)
                return;

            var frameTime = task.Result.Time;
            var frameImage = task.Result.Image;
            Dispatcher.BeginInvoke(new Action(() => ShowFrame(frameTime, frameImage)));
        });
    }
}