c# – 为什么Thread.Join()在UI线程上调用时不挂起我的应用程序?

在我的理解中(我在线程方面不擅长),Join()阻塞调用线程,直到调用Join()的线程返回.

如果这是真的并且从UI线程调用了Join(),则为某些长时间运行的操作创建新线程没有任何意义.有些问题,那些问为什么Join()挂起应用程序.这看起来很自然.

顺便说一下,即使它看起来很自然,我的应用程序也没有相应的行为.它不会挂起我的应用程序.

没有挂起应用程序的线程的代码: –

string retValue = "";
retValue = LongRunningHeavyFunction();
txtResult.Text = retValue;

带有不挂应用程序的线程的代码: –

string retValue = "";
Thread thread = new Thread(
() =>
{
    retValue = LongRunningHeavyFunction();
});
thread.Start();
thread.Join();
txtResult.Text = retValue;

上面的代码很好,没有挂起应用程序函数调用大约需要15-20秒.为什么应用程序不挂起?

这对我来说不是问题;实际上这是一个好消息.但我只是不明白它有什么不同?它与我阅读和学习的内容不符.

如果重要的话,我正在使用DotNet Framework 4.0.

最佳答案
由于Main()入口点上的[STAThread]属性,程序的UI线程创建了一个STA,一个单线程的公寓.还要查看Thread.SetApartmentState(). STA对非线程安全的代码非常友好,通常是您无法看到的代码,因为它是另一个程序的一部分.

就像将数据放入剪贴板所涉及的代码一样,在拖放操作中提供数据,在显示OpenFiledialog时激活的shell扩展,像WebBrowser这样的控件需要客户端代码才能拥有调度程序以便它可以引发DocumentCompleted事件,监听通知的Windows挂钩,依赖可访问性API实现UI自动化的代码或屏幕阅读器.等等.

即使涉及不同进程中的多个线程,也不需要该代码是线程安全的.一般来说,编写线程安全的代码很困难,因为没有任何好的方法让作者测试它,所以它变得非常困难.他无法对可能激活其代码的每个可能程序进行测试.公寓是为解决这个问题而发明的,无需编写线程安全的代码.

STA是您的承诺.你发誓,交叉你的心 – 希望死的风格,你的UI线程表现良好,它必须有一个调度程序(也称为泵消息循环),绝不能阻止.调度程序是以线程安全的方式运行代码所必需的,它是producer-consumer problem的通用解决方案.您必须永远不要阻塞,因为这样做很可能会导致其他程序员代码死锁.您无法调试的死锁类型,因为您没有该代码的源代码. Winforms,WPF或Modern UI程序的UI线程始终实现此承诺,这是UI线程与您可能使用的任何其他线程不同的基本原因.

足够的介绍,Thread.Join()调用块,从而违反了STA合同.这是非常糟糕的CLR设计师did something about it.他们通过不阻塞来实现Join(),如果你发现它在STA线程上被调用.

他们通过实现Application.DoEvents()的味道来做到这一点.这是一种非常臭名昭着的方法,可以避免UI线程变得无法响应.它可能导致很难诊断重入错误.它们的版本并不像DoEvents()那么糟糕,它对于允许调度哪种消息以最小化风险非常有选择性.

这通常没问题,但是从来没有你想要故意测试自己.重新入侵的错误是非常严重的错误,与线程竞争错误一样糟糕.因此,您应该永远不要在UI线程上使用Thread.Join(). .NET Framework为BackgroundWorker和Task类提供了很好的替代方案,它们在线程完成时为您提供了执行代码的非常好的方法(无论是在Join()调用之后).

转载注明原文:c# – 为什么Thread.Join()在UI线程上调用时不挂起我的应用程序? - 代码日志