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

Question

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

一般来说

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

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

特别

我的申请包括

Presentation使用 GUI 工具包创建和管理对话框，

Kernel了解应用程序领域的所有信息，

Controller知道Kernel和 Presentation并介于这两者之间。

更准确地说，这是打开文件的方式:

Presentation发出信号 FileOpenCommand .

ApplicationController接收到这个信号并且

使用 ApplicationKernel创建 File对象，

使用 ApplicationPresentation创建 FilePresentation对象，

创建一个 FileController对象，通过 File和 FilePresentation给构造函数。

FileController在其 File 上将自己注册为观察者和 FilePresentation .

假设 File提供长时间运行的操作 Init()这不应该阻止用户界面。我想到了两种方法:

File::Init()返回一个封装线程的对象，可用于注册一个观察者，该观察者会收到有关进度、错误、完成等的通知。这将很多责任置于 FileController 中。 (谁将成为观察者)，因为现在可以从主线程和工作线程访问它。

对 Controller 完全隐藏工作线程. File::Init()不会返回任何内容，但 ApplicationKernel将发出主线程中长时间运行操作的创建、进度和错误的信号。这将通过ApplicationKernel 拖大量通信。 ，将其变成神物之类的东西。

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

Answer 1

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

编辑

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

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

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

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

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

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