多线程

Question

我当前正在使用的应用程序执行一些I / O或CPU密集型操作（文件压缩，文件传输，与第三方API通信等），这些操作在用户按下“发送”按钮时发生。

我目前正在努力说服我的雇主，我们应该将这些操作推送到主应用程序内部的单独线程中（在任何给定时间，我们最多需要两个工作线程处于活动状态），但是我的同事声称：

在低优先级线程上执行的任何其他处理都可能影响GUI的可用性。

我的观点是，将I / O或CPU密集型活动推送到工作线程，在进度报告过程中使用Invoke调用更新UI，是处理密集型活动的相当标准的做法。

我不正确吗？ 如果是这样，有人可以提供解释吗？

编辑：

到目前为止，谢谢您的回答。

我应该澄清一下：同事的非阻塞解决方案是生成一个包含计时器循环的子进程，该计时器循环扫描文件夹并处理文件压缩/传输活动。 （请注意，这不包括对第三方API的调用-我不知道他的解决方案会有什么。

这种方法的主要问题是，主应用程序失去了任何活动状态的所有范围。这导致恕我直言，进一步复杂（他的进度报告解决方案是在两个进程中公开Windows消息泵，并在两个进程之间发送自定义消息这两个过程）。

Answer 1

你是对的。 就像您所描述的那样，后台线程是通过Invoke操作保持UI处于活动状态的本质。 将所有内容保留在GUI线程上，最终将阻塞运行并使GUI无响应。

Answer 2

最终的答案是将其实现为概念验证，然后对应用进行概要分析，以查看可能存在或不存在什么样的潜在性能影响。 也许在

话虽如此-对我来说听起来像垃圾。 实际上，情况恰恰相反-使用额外的线程通常是保持UI响应能力的最佳方法。

尤其是对于任务并行库之类的东西，基本的多线程并不是很困难。

Answer 3

是的，你是对的。 一般原则是，永远不要使用负责响应用户并保持用户界面最新的线程（通常称为UI线程）执行任何冗长的操作。
根据经验，任何可能花费超过30ms的时间都可以从UI线程中删除。 这有点激进-30ms是大多数人认为不是瞬时的任何东西的最短间隔，实际上比电影屏幕上显示的连续帧之间的间隔稍短。