功能实现:过程或线程部门

Functionality implementation: Processes or Threads division?

本文关键字：线程部 过程 实现 功能      更新时间：2023-10-16

我正在处理要在嵌入式Linux平台上运行的应用程序（与图形零件的QT结合使用）。我需要知道如何以不同的"内核"将应用程序划分为每个应用程序的不同部分，以提高应用程序本身的稳定性，效率和安全性。

我的疑问是：将功能分为线程或分叉不同的过程更方便？

让我提供应用程序的功能视图：每个用户界面都有不同的界面，每个用户界面允许用户或多或少地做相同的事情（不介意数据一致性，我已经解决了这个问题）。这些接口中的每一个都必须充当独立的（例如同一系统的不同终端）。我希望他们所有人都从相同的"核心"发送和接收消息，这将负责更新应用程序数据或做其他适当的事情。

实现内部"核心"和用户界面之间的划分的最佳方法是什么？

可以肯定的是我缺少一些知识，但是到目前为止，我提出了两种选择：1-从父亲"核心"的孩子分配一个孩子，让孩子执行特定的UI程序（我没有实践经验，因此在这种情况下，我可以让父亲和孩子交流（牢记孩子是一个孩子新过程）？）2-为每个核心和UI创建不同的线程。

我需要此部门，因为在崩溃的情况下，应用程序必须尽可能稳定，并且能够重新启动UI。还请记住，总体应用程序将不会具有无限的内存和资源。

事先感谢您的帮助，问候。

有几个原因为什么沿单独的过程路线可能是嵌入式系统中的一个不错的选择：

  • 组件的解耦：作为单独的过程运行组件是最终的解耦。当项目变得非常大

    • 时通常有用

  • 安全性和特权管理：在嵌入式系统中很可能有些组件需要提高特权才能控制设备尽可能多的特权。其他可能的方案是需要实时线程或能够mmap()大量系统内存的组件。任何一个的总体分配将以无法从中恢复的方式锁定您的系统。

  • 可靠：如果系统未能使剩余的运行

    • 失败，则可能会重生

建立这样的安排实际上比这里建议的其他建议更容易 - QT对DBU有很好的支持 - 它很好地照顾了您的IPC，并且在Linux桌面中用于系统管理功能。

。

至于您描述的方案，您可能需要仔细化应用程序的"核心"，然后允许UI组件的DBU上的客户端连接。

在另一个线程中运行UI不会给您带来太大的额外稳定性 - 另一个线程可能会浪费引擎的堆，即使您终止了线程它不会回收的任何资源。

您可以通过在发动机和UI之间具有非常强大的抽象墙来稍微提高稳定性。所以这并不是完全徒劳的。

多个过程需要大量的箍来跳过 - 您需要一种IPC的方法（概要通信）。

请注意，IPC和在较小程度上的抽象墙可能会增加程序的开销。

要问的一个重要问题是" UI和引擎之间必须传递多少数据？" - 如果它的数据足够少（例如从UI到引擎的"启动任务"，并且"此任务已完成为50％"，那么从引擎到UI，IPC就不麻烦了。如果您是图像的实时全屏幕更新，IPC更令人讨厌，更实用。

现在，QT上的快速Google和IPC告诉我，嵌入式Linux有一个QT扩展名，可以允许QT信号和插槽传递过程之间的消息：QT Communications协议（QCOP）。我对这样的框架遇到的一个问题是，与相对简单的协议相比，它可以很容易地导致客户端和服务器状态之间的纠缠。

。
相关文章：