In WPF, explain order of UI updates from Dispatcher vs from event handler

Question

I would like to understand the following behaviour. I have WPF application with button click event handler in which I start Parallel.ForEach. In each loop I update UI via Dispatcher. After the Parallel.Foreach I do the "final update" of the UI. However this "final update" actually happens before any of the updates from the Dispatcher. Why is it happening in this order?

private void btnParallel_Click(object sender, RoutedEventArgs e)
{
    txbResultsInfo.Text = "";

    Parallel.ForEach(_files, (file) =>
    {
        string partial_result = SomeComputation(file);

        Dispatcher.BeginInvoke(new Action(() =>
        {
            txbResultsInfo.Text += partial_result + Environment.NewLine;
        }));
    });

    txbResultsInfo.Text += "-- COMPUTATION DONE --"; // THIS WILL BE FIRST IN UI, WHY?
    //Dispatcher.BeginInvoke(new Action(() => txbResultsInfo.Text += "-- COMPUTATION DONE --"; - THIS WAY IT WILL BY LAST IN UI
}

My intuitive expectation was that the code continues after all branches of the Parallel.ForEach loops are finished, meaning the Dispatcher has received all requests for UI update and started to execute them and only then we continue to update the UI from the rest of the handler method. But the "-- COMPUTATION DONE --" actually always appears first in the textBlock. Even if I put Task.Delay(5000).Wait() before the "done computation" update. So it is not just a matter of speed, it is actually sorted somehow that this update is happening before updates from Dispatcher.

If I put the "done computation" update to dispatcher as well, it behaves as I would expect and is at the end for the text. But why does this needs to be done via dispatcher as well?

That is very weird indeed. Normally the `Parallel.ForEach` method should wait untill everything's finished and then go further... Maybe if you add `.IsCompleted` at the end of the foreach? (though I don't think that's gonna fix it) — baltermia, Apr 22 '21 at 15:14
I will point out that since this is WPF code, for your code to be setting UI properties directly is simply wrong anyway. You should be using data binding, and letting the WPF framework handle cross-thread dispatch. That won't necessarily change what you're seeing above, but it will at least be better code. — Peter Duniho, Apr 22 '21 at 16:54
`BeginInvoke()` doesn't wait. It simply _queues_ your dispatched delegate and returns. In your example, all of the dispatched delegates are queued by `Parallel.ForEach()` which is blocking the UI thread that would otherwise invoke the queued delegates, so that method returns and lets the assignment to `txbResultsInfo.Text` happen before any of the queued delegates get to actually be called. See duplicate for more details (all of the `BeginXXX()` vs `XXX()` methods work this way). — Peter Duniho, Apr 22 '21 at 18:58

Theodor Zoulias · Accepted Answer · 2021-04-22T17:13:42.230

The Parallel.ForEach is a blocking method, meaning that the UI thread is blocked during the parallel execution. So the actions posted to the Dispatcher cannot be executed, and instead they are buffered in a queue. After the completion of the parallel execution the code continues running until the end of the event handler, and only then the queued actions are executed. This behavior not only messes up the order of the progress messages, but also makes the UI not-responsive, which is probably equally annoying.

To fix both problems you should avoid running the parallel loop on the UI thread, and instead run it on a background thread. The easier way to do it is to make your handler async, and wrap the loop in an await Task.Run like this:

private async void btnParallel_Click(object sender, RoutedEventArgs e)
{
    txbResultsInfo.Text = "";

    await Task.Run(() =>
    {
        Parallel.ForEach(_files, (file) =>
        {
            string partial_result = SomeComputation(file);

            Dispatcher.BeginInvoke(new Action(() =>
            {
                txbResultsInfo.Text += partial_result + Environment.NewLine;
            }));
        });
    });

    txbResultsInfo.Text += "-- COMPUTATION DONE --";
}

But honestly using the Dispatcher for reporting progress is an old and awkward approach. The modern approach is to use the IProgress<T> abstraction. Here is how you could use it:

private async void btnParallel_Click(object sender, RoutedEventArgs e)
{
    txbResultsInfo.Text = "";
    IProgress<string> progress = new Progress<string>(message =>
    {
        txbResultsInfo.Text += message;
    });

    await Task.Run(() =>
    {
        Parallel.ForEach(_files, (file) =>
        {
            string partial_result = SomeComputation(file);
            progress.Report(partial_result + Environment.NewLine);
        });
    });
    progress.Report("-- COMPUTATION DONE --");
}

In case the above code is not self-explanatory, an extended tutorial can be found here: Enabling Progress and Cancellation in Async APIs

Side note: The default behavior of the Parallel.For/Parallel.ForEach methods is to saturate the ThreadPool, which can be quite problematic, especially for async-enabled applications. For this reason I recommend specifying explicitly the MaxDegreeOfParallelism option, every time these methods are used:

Parallel.ForEach(_files, new ParallelOptions()
{
    MaxDegreeOfParallelism = Environment.ProcessorCount
}, (file) =>
{
    //...
});

In WPF, explain order of UI updates from Dispatcher vs from event handler

1 Answers1