使用 STA 时表单表现异常,线程耗时过长
Form behaving weirdly when using STA and threads take too long
我们正在用 C# 开发一个多线程游戏引擎,我们遇到了一个问题,我们需要 STAThread 属性(或手动将我们的线程设置为 STA)来启用拖放支持(AllowDrop 不能设置无 STA)。但是,当我们启用 STA 并且更新方法比绘制方法花费的时间更长时(如下所示),window 不再正常运行 - 当它在任务栏中单击时,它不会最小化和最大化如您所料。确切的行为在不同的系统上是不同的,我猜这里会出现某种竞争条件。
这是我们的测试代码:
[STAThread]
public static void Main()
{
Form form = new Form();
form.Show();
Barrier barrier = new Barrier(2);
Thread updateThread = new Thread(() => {
while (true)
{
barrier.SignalAndWait();
Thread.Sleep(30); //Update
barrier.SignalAndWait();
}
});
updateThread.Start();
while (true)
{
barrier.SignalAndWait();
Thread.Sleep(15); //Draw
barrier.SignalAndWait();
Application.DoEvents();
}
}
我认识到这个问题,我在 Vista 时代的一个非托管应用程序中调试了一个非常相似的问题。该问题非常隐蔽,与您通过单击任务栏按钮生成的非常喜怒无常的 WM_ACTIVATEAPP 消息有关。特别是当它由嵌套消息循环调度并且该循环进行消息过滤以仅允许调度某些 "safe" 消息时。
这是由 Barrier.SignalAndWait() 调用引起的。这会阻塞 UI 线程并且对于 STA 线程来说是非法的。 CLR 对此做了一些事情,它在底层同步对象未发出信号时泵出自己的消息循环。如果是 那个 循环调度 WM_ACTIVATEAPP,并且可能性非常高,因为你阻塞了 30 毫秒并且只泵了一次,那么它就会出错。由于某些神秘的原因,后续消息不会被发送。几乎可以肯定是由该消息循环完成的过滤引起的。否则很难看到,该代码从未发布过,也无法反编译。
它是可以修复的,但并不容易。解决方法是强制 CLR not 抽取此消息循环。这没关系,因为您的等待时间很短。您可以通过重写 SynchronizationContext.Wait() 方法来执行某些操作。不幸的是,这很难做到,WindowsFormsSynchronizationContext class 是密封的,因此无法从中派生以覆盖其 Wait() 方法。您需要将 Reference Source 和 copy/paste 和 class 访问到您的代码中。给它另一个名字。
我将给出它的简短版本,显示您需要更改的内容:
using System.Runtime.InteropServices;
class MySynchronizationContext : SynchronizationContext {
public MySynchronizationContext() {
base.SetWaitNotificationRequired();
}
public override int Wait(IntPtr[] waitHandles, bool waitAll, int millisecondsTimeout) {
return WaitForMultipleObjects(waitHandles.Length, waitHandles, false, millisecondsTimeout);
}
[DllImport("kernel32.dll")]
static extern int WaitForMultipleObjects(int nCount, IntPtr[] lpHandles,
bool bWaitAll, int dwMilliseconds);
}
并安装新的同步提供程序:
System.ComponentModel.AsyncOperationManager.SynchronizationContext =
new MySynchronizationContext();
简而言之,SetWaitNotificationRequired() 调用告诉 CLR 它应该调用您的 Wait() 覆盖而不是使用它自己的 Wait() 实现。 Wait() 覆盖使用 OS' 阻塞等待而不用其他方式抽取。当我测试它并解决问题时效果很好。
我们正在用 C# 开发一个多线程游戏引擎,我们遇到了一个问题,我们需要 STAThread 属性(或手动将我们的线程设置为 STA)来启用拖放支持(AllowDrop 不能设置无 STA)。但是,当我们启用 STA 并且更新方法比绘制方法花费的时间更长时(如下所示),window 不再正常运行 - 当它在任务栏中单击时,它不会最小化和最大化如您所料。确切的行为在不同的系统上是不同的,我猜这里会出现某种竞争条件。
这是我们的测试代码:
[STAThread]
public static void Main()
{
Form form = new Form();
form.Show();
Barrier barrier = new Barrier(2);
Thread updateThread = new Thread(() => {
while (true)
{
barrier.SignalAndWait();
Thread.Sleep(30); //Update
barrier.SignalAndWait();
}
});
updateThread.Start();
while (true)
{
barrier.SignalAndWait();
Thread.Sleep(15); //Draw
barrier.SignalAndWait();
Application.DoEvents();
}
}
我认识到这个问题,我在 Vista 时代的一个非托管应用程序中调试了一个非常相似的问题。该问题非常隐蔽,与您通过单击任务栏按钮生成的非常喜怒无常的 WM_ACTIVATEAPP 消息有关。特别是当它由嵌套消息循环调度并且该循环进行消息过滤以仅允许调度某些 "safe" 消息时。
这是由 Barrier.SignalAndWait() 调用引起的。这会阻塞 UI 线程并且对于 STA 线程来说是非法的。 CLR 对此做了一些事情,它在底层同步对象未发出信号时泵出自己的消息循环。如果是 那个 循环调度 WM_ACTIVATEAPP,并且可能性非常高,因为你阻塞了 30 毫秒并且只泵了一次,那么它就会出错。由于某些神秘的原因,后续消息不会被发送。几乎可以肯定是由该消息循环完成的过滤引起的。否则很难看到,该代码从未发布过,也无法反编译。
它是可以修复的,但并不容易。解决方法是强制 CLR not 抽取此消息循环。这没关系,因为您的等待时间很短。您可以通过重写 SynchronizationContext.Wait() 方法来执行某些操作。不幸的是,这很难做到,WindowsFormsSynchronizationContext class 是密封的,因此无法从中派生以覆盖其 Wait() 方法。您需要将 Reference Source 和 copy/paste 和 class 访问到您的代码中。给它另一个名字。
我将给出它的简短版本,显示您需要更改的内容:
using System.Runtime.InteropServices;
class MySynchronizationContext : SynchronizationContext {
public MySynchronizationContext() {
base.SetWaitNotificationRequired();
}
public override int Wait(IntPtr[] waitHandles, bool waitAll, int millisecondsTimeout) {
return WaitForMultipleObjects(waitHandles.Length, waitHandles, false, millisecondsTimeout);
}
[DllImport("kernel32.dll")]
static extern int WaitForMultipleObjects(int nCount, IntPtr[] lpHandles,
bool bWaitAll, int dwMilliseconds);
}
并安装新的同步提供程序:
System.ComponentModel.AsyncOperationManager.SynchronizationContext =
new MySynchronizationContext();
简而言之,SetWaitNotificationRequired() 调用告诉 CLR 它应该调用您的 Wait() 覆盖而不是使用它自己的 Wait() 实现。 Wait() 覆盖使用 OS' 阻塞等待而不用其他方式抽取。当我测试它并解决问题时效果很好。