How is Progress different from Action?

Question

I've been using Progress<T> and wondered if it can be replaced by Action<T>.

In the code below, using each of them for reporting progress, i.e. ReportWithProgress() or ReportWithAction(), didn't make any noticeable difference to me. How progressBar1 increased, how the strings were written on the output window, they seemed the same.

// WinForm application with progressBar1

private void HeavyIO()
{
    Thread.Sleep(20); // assume heavy IO
}

private async Task ReportWithProgress()
{
    IProgress<int> p = new Progress<int>(i => progressBar1.Value = i);

    for (int i = 0; i <= 100; i++)
    {
        await Task.Run(() => HeavyIO()); 
        Console.WriteLine("Progress : " + i);
        p.Report(i);
    }
}

private async Task ReportWithAction()
{
    var a = new Action<int>(i => progressBar1.Value = i);

    for (int i = 0; i <= 100; i++)
    {
        await Task.Run(() => HeavyIO());
        Console.WriteLine("Action : " + i);
        a(i);
    }
}

But Progress<T> can't be a reinvention of the wheel. There should be a reason why it was implemented. Googling "c# Progress vs Action" didn't give me much help. How is Progress different from Action?

I'd suggest you to change `HeavyIO` to `async Task HeavyIO() { await Task.Delay(20); }` so that at least you are invoking a Task — Camilo Terevinto, Feb 05 '18 at 14:52
`Progress` calls the action in the context in which it was constructed which allows you to interact with the UI without annoying invocation code. — DavidG, Feb 05 '18 at 14:55
What information did you find in the documentation of `Progress` and how did that fail to answer your question? — Servy, Feb 05 '18 at 14:57
Calling `progressBar1.Value = i` from a different thread results in the dreaded ["cross-thread operation not valid"](https://stackoverflow.com/q/10775367/69809) exception. — vgru, Feb 05 '18 at 15:03
Note that [`Progress` is a *class*](https://referencesource.microsoft.com/#mscorlib/system/progress.cs,d23df0450d3fd0d6), while [`Action` is merely a delegate](https://referencesource.microsoft.com/#mscorlib/system/action.cs,486d58da4553e12d). — Matthew Watson, Feb 05 '18 at 15:15

vgru · Accepted Answer · 2018-02-05T15:18:27.593

Calling progressBar1.Value = i from a different thread results in the dreaded "cross-thread operation not valid" exception. The Progress class, on the other hand, dispatches the event to the synchronization context captured in the moment of construction:

// simplified code, check reference source for actual code

void IProgress<T>.Report(T value)
{
    // post the processing to the captured sync context
    m_synchronizationContext.Post(InvokeHandlers, value);
}

private void InvokeHandlers(object state)
{
    // invoke the handler passed through the constructor
    m_handler?.Invoke((T)state);

    // invoke the ProgressChanged event handler
    ProgressChanged?.Invoke(this, (T)state);
}

This ensures that all updates to progress bars, labels and other UI elements are done on a (one and only) GUI thread.

So, it only makes sense to instantiate the Progress class outside of the background thread, inside a method which is called on a UI thread:

void Button_Click(object sender, EventArgs e)
{
    // since this is a UI event, instantiating the Progress class
    // here will capture the UI thread context
    var progress = new Progress<int>(i => progressBar1.Value = i);

    // pass this instance to the background task
    Task.Run(() => ReportWithProgress(progress));
}

async Task ReportWithProgress(IProgress<int> p)
{
    for (int i = 0; i <= 100; i++)
    {
        await Task.Run(() => HeavyIO());
        Console.WriteLine("Progress : " + i);
        p.Report(i);
    }
}

@ChrFin: Well, the "one and only" thread to which your Form's controls are bound to. — vgru, Feb 05 '18 at 15:19

Christoph Fink · Answer 2 · 2018-02-05T15:22:32.440

The difference is that with a Progress<T> you have an event where multiple listeners can listen for progress and Progress<T> does capture the SynchonizationContext when the instance is constructed and thus does not need to be invoked to the GUI-thread if created in the GUI-thread.
You can also add multiple listeners to an Action<T> (thanks to @Servy for pointing that out), but each of them are then executed in the thread which invokes the action.

Think of the following extended example, where the Progress<T> will work, but the Action<T> will throw an exception:

private async Task ReportWithProgress()
{
    var p = new Progress<int>(i => progressBar1.Value = i);
    p.ProgressChanged += (s, e) => progressBar2.Value = e;

    Task.Run(() => 
        {
            for (int i = 0; i <= 100; i++)
            {
                await Task.Run(() => HeavyIO()); 
                Console.WriteLine("Progress : " + i);
                ((IProgress<int>)p).Report(i);
            }
        });
}

private async Task ReportWithAction()
{
    var a = new Action<int>(i => progressBar1.Value = i);
    a += i => progressBar2.Value = i;

    Task.Run(() => 
        {
            for (int i = 0; i <= 100; i++)
            {
                await Task.Run(() => HeavyIO());
                Console.WriteLine("Action : " + i);
                a(i);
            }
        });
}

`Action` is a multicast delegate. Any number of methods can be called when you invoke it. — Servy, Feb 05 '18 at 14:55

How is Progress different from Action?

2 Answers2

Linked