为什么 InvokeRequired 优于 WindowsFormsSynchronizationContext？

Question

任何时候初学者问类似：How to update the GUI from another thread in C#?，答案都很直接：

if (foo.InvokeRequired)
{
    foo.BeginInvoke(...)
} else {
    ...
}

但是真的好用吗？在非 GUI 线程执行 foo.InvokeRequired 之后，foo 的状态可以改变。例如，如果我们在foo.InvokeRequired 之后但在foo.BeginInvoke 之前关闭窗体，则调用foo.BeginInvoke 将导致InvalidOperationException：在创建窗口句柄之前，不能在控件上调用Invoke 或BeginInvoke。 如果我们在调用InvokeRequired 之前关闭表单就不会发生这种情况，因为即使从非GUI 线程调用它也会是false。

另一个例子：假设foo 是TextBox。如果您关闭表单，并且在该非 GUI 线程执行 foo.InvokeRequired（这是错误的，因为表单已关闭）和 foo.AppendText 之后，它将导致 ObjectDisposedException。

相比之下，在我看来，使用WindowsFormsSynchronizationContext 更容易——只有当线程仍然存在时才会使用Post 发布回调，如果线程不再存在，使用Send 的同步调用会抛出InvalidAsynchronousStateException。

使用WindowsFormsSynchronizationContext 不是更简单吗？我错过了什么吗？如果 InvokeRequired-BeginInvoke 模式不是真正的线程安全，为什么要使用它？你觉得哪个更好？

Answer 1

WindowsFormsSynchronizationContext 通过将自身附加到一个特殊控件来工作，该控件绑定到创建上下文的线程。

所以

if (foo.InvokeRequired)
{
    foo.BeginInvoke(...)
} else {
    ...
}

可以换成更安全的版本：

context.Post(delegate
{
    if (foo.IsDisposed) return;
    ...
});

假设 context 是在 foo 所在的同一 UI 线程上创建的 WindowsFormsSynchronizationContext。

这个版本避免了你引起的问题：

在非 GUI 线程执行 foo.InvokeRequired 之后，foo 的状态可以改变。例如，如果我们在 foo.InvokeRequired 之后但在 foo.BeginInvoke 之前关闭窗体，则调用 foo.BeginInvoke 将导致 InvalidOperationException：在创建窗口句柄之前无法在控件上调用 Invoke 或 BeginInvoke。如果我们在调用 InvokeRequired 之前关闭表单就不会发生这种情况，因为即使从非 GUI 线程调用它也会为假。

---

如果您使用多个消息循环或多个 UI 线程，请注意 WindowsFormsSynchronizationContext.Post 的一些特殊情况：

• WindowsFormsSynchronizationContext.Post 仅当创建它的线程上仍有消息泵时才会执行委托。如果没有什么都没有发生并且没有引发异常。
  另外，如果稍后将另一个消息泵附加到线程（例如通过第二次调用Application.Run），委托将执行（这是因为系统为每个线程维护一个消息队列，但不知道有人是否从其中抽取消息）
• WindowsFormsSynchronizationContext.Send 将抛出 InvalidAsynchronousStateException 如果它绑定的线程不再活动。但是如果它绑定的线程是存活的并且没有运行消息循环它不会立即执行但是仍然会被放置在消息队列中并且如果再次执行Application.Run 就会被执行。

如果在自动释放的控件（如主窗体）上调用 IsDisposed，则这些情况都不会意外执行代码，因为即使在意外时间执行委托也会立即退出。

危险的情况是调用WindowsFormsSynchronizationContext.Send 并考虑到代码将被执行：它可能不会，现在有办法知道它是否做了任何事情。

---

我的结论是WindowsFormsSynchronizationContext 是一个更好的解决方案，只要正确使用。

它可以在复杂的情况下产生微妙的问题，但常见的 GUI 应用程序只有一个消息循环，只要应用程序本身一直正常运行，它就会一直存在。

Answer 2

谁说InvokeRequired/Control.BeginInvoke是首选？如果您问我，在大多数情况下，出于您提到的确切原因，这是一种反模式。您链接到的问题有很多答案，有些确实建议使用同步上下文（包括mine）。

虽然确实可以在您尝试从发布的委托访问它时释放任何给定的控件，但使用Control.IsDisposed 可以轻松解决这个问题（因为您的委托在 UI 线程上执行，因此没有任何东西可以释放控件当它运行时）：

public partial class MyForm : Form
{
    private readonly SynchronizationContext _context;
    public MyForm()
    {
        _context = SynchronizationContext.Current
        //...
    }

    private MethodOnOtherThread()
    {
         //...
         _context.Post(status => 
          {
             // I think it's enough to check the form's IsDisposed
             // But if you want to be extra paranoid you can test someLabel.IsDisposed
             if (!IsDisposed) {someLabel.Text = newText;}
          },null);
    }
}