Question

I inherited some code that has two non-UI threads that update various WinForm controls.
The code is using InvokeRequired and Invoke to update the UI; however, I still once in a while get the error: Cross-thread operation not valid: Control ‘lvReports’ accessed on a thread other than it was created on.

I suspect I am dealing with a race condition and that I need to introduce a lock into the method below, but that said, I can find dozens of examples on how to update UI from a non-UI thread safely but no examples or discussion on how to deal with two threads updating the same controls in a race scenario.

So my question is: how do I rewrite the code below to handle updating the UI properly given a race condition and that I need to update UI from non-UI threads?

// two separate theads call this method in a instance of a WinForm
private void LoadReports()
{
  if (this.InvokeRequired)
  {
    this.Invoke(new MethodInvoker(this.LoadReports));
  }
  else
  {
    // some code removed to keep exampe simple...
    SetCtlVisible(lvReports, true);

    if (this.InvokeRequired)
    {
      this.Invoke((MethodInvoker)delegate { lvReports.Refresh(); });
    }
    else
    {
       lvReports.Refresh();
    }
  }
}

delegate void SetVisibleCallback(Control ctl, bool visible);
private void SetCtlVisible(Control ctl, bool visible)
{
  if (ctl.InvokeRequired)
  {
    SetVisibleCallback d = new SetVisibleCallback(SetCtlVisible);
    ctl.Invoke(d, new object[] { ctl, visible });
  }
  else
  {
    ctl.Visible = visible;
  }
}

Here are some thoughts:
Does this.InvokeRequired differ from ctl.InvokeRequired at any time?
Is the second InvokeRequired test needed given the first?
Is the implementation of SetCtlVisible needed if I keep the first InvokeRequired?
Should I delete the first InvokeRequired and keep all the code in the else clause?
Is lock needed around the else clause?

Answer 1

Using InvokeRequired like this is an anti-pattern. You know that this method is getting called from a thread, InvokeRequired should always be true.

Now you can use it to troubleshoot your problem. If it is false then there’s something seriously wrong. Throw an exception, the debugger will stop and let you find out why it isn’t working properly. And always call Invoke(), invoke to a little helper method that does the rest of LoadReports().

Also note that you are using it wrong in the rest of your code. You know that the remainder of LoadReports() runs on the UI thread, you used Invoke(). No point in testing it again, including inside SetCtlVisible().

The typical reason for getting the bomb is because the thread is running LoadReports() too soon, before the form’s window is created. You need to interlock that. The form’s Load event is the signal.