从多个线程更新 IProgress 是否安全？

Question

I have some c# code (MVC WebAPI) which iterates over an array of IDs in parallel and makes an API call for each entry. In the first version, the whole code was a simple, synchronous for loop. Now we changed that to a combination of Task.WhenAll and a LINQ select:

private async Task RunHeavyLoad(IProgress<float> progress) {
  List<MyObj> myElements = new List<MyObj>(someEntries);
  float totalSteps = 1f / myElements.Count();
  int currentStep = 0;

  await Task.WhenAll(myElements.Select(async elem => {
    var result = await SomeHeavyApiCall(elem);
    DoSomethingWithThe(result);
    progress.Report(totalSteps * System.Threading.Interlocked.Increment(ref currentStep) * .1f);
  }

  // Do some more stuff
}

This is a simplified version of the original method! The actual method EnforceImmediateImport is called by this SignalR hub method:

public class ImportStatusHub : Hub {
  public async Task RunUnscheduledImportAsync(DateTime? fromDate, DateTime? toDate) {
    Clients.Others.enableManualImport(false);

    try {
      Progress<float> progress = new Progress<float>((p) => Clients.All.updateProgress(p));
      await MvcApplication.GlobalScheduler.EnforceImmediateImport(progress, fromDate, toDate);

    } catch (Exception ex) {
      Clients.All.importError(ex.Message);
    }

    Clients.Others.enableManualImport(true);
  }
}

Now I wonder, if this is "thread safe" per se, or if I need to do something with the progress.Report calls to prevent anything from going wrong.

Answer 1

From the docs :

Remarks

Any handler provided to the constructor or event handlers registered with the ProgressChanged event are invoked through a SynchronizationContext instance captured when the instance is constructed. If there is no current SynchronizationContext at the time of construction, the callbacks will be invoked on the ThreadPool.

For more information and a code example, see the article Async in 4.5: Enabling Progress and Cancellation in Async APIs in the .NET Framework blog.

Like anything else using the SynchronizationContext , it's safe to post from multiple threads.

Custom implementations of IProgress<T> should have their behavior defined.

Answer 2

On your question, internally, Progress only does invoking. It is up to the code you wrote to handle the progress on the other side. I would say that the line progress.Report(totalSteps * System.Threading.Interlocked.Increment(ref currentStep) *.1f); can cause a potential progress reporting issue due to the multiplication which is not atomic.

This is what happens internally inside Progress when you call Report

  protected virtual void OnReport(T value)
  {
      // If there's no handler, don't bother going through the sync context.
      // Inside the callback, we'll need to check again, in case 
      // an event handler is removed between now and then.
      Action<T> handler = m_handler;
      EventHandler<T> changedEvent = ProgressChanged;
      if (handler != null || changedEvent != null)
      {
          // Post the processing to the sync context.
          // (If T is a value type, it will get boxed here.)
          m_synchronizationContext.Post(m_invokeHandlers, value);
      }
  }

On the code though, a better way to run in parallel is to use PLinq. In your current code, if the list contains many items, it will spin up tasks for every single item at the same time and wait for all of them to complete. However, in PLinq, the number of concurrent executions will be determined for you to optimize performance.

myElements.AsParallel().ForAll(async elem =>
{
    var result = await SomeHeavyApiCall(elem);
    DoSomethingWithThe(result);
    progress.Report(totalSteps * System.Threading.Interlocked.Increment(ref currentStep) * .1f);
}

Please keep in mind that AsParallel().ForAll() will immediately return when using async func. So you might want to capture all the tasks and wait for them before you proceed.

One last thing, if your list is being edited while it is being processed, i recommend using ConcurrentQueue or ConcurrentDictionary or ConcurrentBag.