为什么 InvokeRequired 优于 WindowsFormsSynchronizationContext？

Question

任何时候初学者问这样的问题： 如何从另一个更新 GUI 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 （这是 false，因为表单已关闭）和 foo.AppendText 它将导致 ObjectDisposeException.

相反，在我看来，使用 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 线程调用它也会为 false。

---

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

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

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

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

---

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

在复杂的情况下，它可能会产生微妙的问题，但具有一个消息循环的常见 GUI 应用程序，只要应用程序本身存在，就总是没问题。

Answer 2

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

虽然任何给定的控件确实可以在您尝试从发布的委托访问它时被释放，但这可以使用 Control.IsDispose （当您的委托在 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);
    }
}