使用STA时线程表现很奇怪,线程花费的时间太长

Question

我们正在用C#开发一个多线程游戏引擎,我们遇到了一个问题,我们需要STAThread属性(或者手动将我们的线程设置为STA)以启用拖放支持(如果没有STA,就不能设置AllowDrop).但是,当我们启用STA并且更新方法比draw方法花费的时间更长时(如下所示),窗口不再正常运行 - 当它在任务栏中单击时,它不会像您期望的那样最小化和最大化它.不同系统的确切行为是不同的,我猜这种竞争条件会起作用.

这是我们的测试代码:

    [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();
        }
    }

Answer 1

我意识到这个问题,我在一个非托管应用程序的Vista中调试了一个非常类似的问题.问题非常模糊,与您通过单击任务栏按钮生成的非常不稳定的WM_ACTIVATEAPP消息有关.特别是当它由嵌套的消息循环调度时,该循环进行消息过滤以仅允许分派某些"安全"消息.

它是由Barrier.SignalAndWait()调用引起的.这会阻止UI线程,这对于STA线程来说是非法的.CLR对此做了一些事情,它在没有信号通知底层同步对象的情况下泵送自己的消息循环.如果是那个调度WM_ACTIVATEAPP的循环,并且赔率非常高,因为你阻塞30毫秒并且只抽一次,那么它就出错了.由于某些神秘的原因,后续消息不会被分派.几乎肯定是由该消息循环完成的过滤引起的.否则很难看,该代码从未发布过,也无法反编译.

它是可以修复的,但不容易.解决方法是强制CLR 不泵送此消息循环.哪个是好的,因为你的等待时间很短.你可以通过重写SynchronizationContext.Wait()方法做的事情.不幸的是,这很难做到,WindowsFormsSynchronizationContext类是密封的,因此无法派生来覆盖其Wait()方法.您需要访问参考源并将该类复制/粘贴到您的代码中.给它另一个名字.

我会给出它的简短版本,显示你需要改变的内容:

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'阻塞等待而不进行其他泵送.当我测试并解决问题时工作得很好.