多线程应用概念

Question

对于将代码组织成不同的功能单元(很可能是线程？)，我有一个小小的架构疑问。正在开发的应用程序应该执行以下任务：

1. 在屏幕上显示一些图像(即幻灯片)
2. 通过USB端口从外部设备读取数据。
3. 将接收到的数据与相应的图像(刺激)相匹配
4. 做一些数据分析
5. 绘制数据分析结果

我的想法是将应用程序组织成以下模块：

1. GUI线程(+图像幻灯片)
2. USB线程缓冲接收到的数据
3. 用于分析/绘制数据的线程(在绘制数据时不应阻塞主GUI线程，这可能会占用更多时间)

那么，你对这个概念一般是怎么看的？你认为在这种特殊情况下还有什么更适合的吗？

Answer 1

这在很大程度上取决于执行3所涉及的内容(做一些数据分析)。4(地块分析数据)。

我的直觉是：

当然有一个单独的线程来读取USB上的数据。假设3依赖于读取数据，那么我将在与读取数据相同的线程中执行3。这将简化数据准备好后发送给GUI的信令。这还假设处理速度快，不会阻塞USB端口(如何读取？)完成端口？)。如果处理需要时间，那么您需要一个单独的线程。

同样，如果图像幻灯片处理显示需要很长时间，这应该在一个单独的线程中完成。如果这可以快速重新计算，这取决于在一个油漆函数，我将保留它作为主要GUI的一部分。

线程的上下文切换存在一些开销，每个线程都增加了信令的复杂性。因此，我只添加一个线程来解决GUI和USB端口的阻塞问题。只需两个线程就可以完成所有这一切。

Answer 2

您可能可以通过合并1和2，因为幻灯片显示功能本质上是面向gui的。

对于#3，您可能可以使用某种异步I/O方法，这样就不需要专门使用轮询线程。不确定您是否可以使用USB来完成这个任务，但是您肯定可以获得带有串行和网络接口的异步I/O，因此值得研究。

把像4&5这样的重量级任务转移到自己的线程上可能是个好主意。如果您没有同时进行分析和绘图，则可能为它们都执行一条线程。但是，您应该真正考虑这些活动需要多少cpu时间。如果最坏的情况分析和绘图所需时间远远少于半秒钟，您甚至可以使用gui调用来执行这些操作。相反，如果在某些情况下，这将花费更长的时间，那么单独的线程是有利的b/c，您的用户不会喜欢滞后的gui。

请记住，线程的阴暗面在于协调它们的不可避免的挑战。

Answer 3

由于Windows的工作方式，特别是在用户输入和窗口所有权方面。您实际上只能在一个线程上执行UI。如果您尝试使用多个线程，它们最终只会锁定对方，每次只运行一个线程。虽然有一些特殊的例外情况，但您必须真正掌握API才能实现它。

所以。

1. GUI线程，拥有该窗口，并处理所有用户输入。
2. USB监听线程，你会比我更清楚这是否有意义。
3. 对于分析/绘制数据的线程，我再一次说不出话来，但我怀疑它们是否真的同时运行。这似乎更有可能，它将被分析，然后绘制一个线程。
4. 用于为幻灯片呈现框架的线程。

我不知道绘图和幻灯片是怎么一回事，但我确实认为你可以有一个背景线程来绘制幻灯片，只要它不显示图像。您可以在后台线程中呈现(即绘制到位图或DirectX图面)，只是不能在窗口中显示。但是您可以将完成的位图交给GUI线程，让它执行位图的实际显示。这基本上就是很多视频回放代码的工作原理。