多线程对桌面应用程序的架构有哪些影响？

Question

我正在编写一个多线程桌面应用程序。

一般

我不确定多线程对架构的影响。有很多关于架构的文献，但我不知道没有考虑到多线程。有很多关于多线程的低级内容（互斥体、信号量等）的文献，但我不知道描述这些概念是如何嵌入到架构中的。

您推荐哪些文献来填补这一空白？

特别是

我的申请包括

• Presentation 使用 GUI 工具包创建和管理对话框，
• Kernel 了解应用程序的所有领域，
• Controller 知道 Kernel 和 Presentation 并介于这两者之间。

更准确地说，文件的打开方式如下：

1. Presentation 表示FileOpenCommand。
2. ApplicationController 收到此信号并
   1. 使用ApplicationKernel 创建File 对象，
   2. 使用ApplicationPresentation 创建FilePresentation 对象，
   3. 创建一个FileController 对象，将File 和FilePresentation 传递给构造函数。
3. FileController 在其File 和FilePresentation 上将自己注册为观察者。

假设File 提供了一个长时间运行的操作Init()，它不应阻塞用户界面。我想到了两种方法：

1. File::Init() 返回一个封装线程的对象，可用于注册一个观察者，该观察者会收到有关进度、错误、完成等的通知。这使FileController（谁将成为观察者）承担了很多责任，因为它现在可以从主线程和工作线程访问。
2. 对Controller 完全隐藏工作线程。 File::Init() 不会返回任何内容，但ApplicationKernel 会发出主线程中长时间运行操作的创建、进度和错误的信号。这会通过ApplicationKernel 拖累大量交流，将其变成类似神物的东西。

这两种方法中哪一种是桌面应用程序中多线程的常用方法（如果有）？您推荐哪些替代方法？

Answer 1

我建议您考虑使用actor model。它是一种并发抽象，隐藏了很多与线程、锁等相关的细节。

编辑

@CMR 的评论引发了一些额外的 cmets...

在演员模型下，我想应用程序仍将使用问题中建议的相同组件来构建：Presentation、ApplicationController 等。与演员模型的区别在于组件（现在是演员) 不会直接相互引用。相反，他们将拥有可以相互发布异步、不可变消息的通道。

“打开文件”案例中的事件顺序在 Actor 模型中基本相同，只是通道将在步骤 2.3 中传递给FileController，而不是直接对象引用。同样，观察者注册也是通过渠道进行的。

那么有什么区别呢？主要区别在于没有任何代码需要是线程感知的。线程对应用程序逻辑是不可见的，这是参与者框架的关注点。如果可以遵循仅通过通道传递不可变对象的原则（某些参与者框架强制执行），那么几乎所有与线程同步相关的困难逻辑都会消失。当然，必须将思维方式从同步编程模型转换为异步编程模型——这不一定是一项微不足道的任务。但是，我认为，不必考虑线程安全（至少在某些复杂的系统中）的好处超过了该开关的成本。

特别是在 UI 编程中，异步模型可以更轻松地提供良好的用户反馈。例如，UI 元素可能会启动一个长时间运行的任务，显示“工作中...”消息，然后进入睡眠状态。一段时间后，一条消息到达，传递长时间运行的任务的结果，然后 UI 元素显示该结果以代替“工作...”消息。以类似的方式，可以随着每个树节点的数据以传入消息的形式逐步构建树视图。

您可以将 Actor 模型视为经典 UI“事件泵”方法的概括——除了每个组件（演员）同时运行自己的事件泵，而不是一个泵分派给一堆组件。 Actor 框架提供了一种以非常低的开销运行大量甚至大量此类“同时泵”的方法。特别是，少量线程（例如，每个 cpu 一个）为大量参与者提供服务。