设计操作系统抽象层答案

【问题标题】：Designing an OS abstraction layer设计操作系统抽象层
【发布时间】：2009-10-31 04:55:46
【问题描述】：

在为多模块系统开发操作系统抽象层时，应该采用哪种方法：

创建一个操作系统服务共享库，每个模块都被构建为使用它并作为单独的进程运行。或
仅创建一个抽象层实例，该实例提供内存、计时器服务并单独生成所有模块实例。

这些方法的优缺点是什么？如果可能的话，还要放下其他的吗？

【问题讨论】：

您支持哪种语言？这将是多线程的，还是如第一个答案中提到的那样，它会支持多核吗？一些限制会有所帮助，希望您的设计不是为了支持大规模并行服务器和嵌入式处理器。
嗨詹姆斯，我知道这是一个很笼统的问题，没有太多细节，但让我补充一些……语言 - 'C' 多线程 - '是' 多核 - '是'并行处理 - 无嵌入式软件 - 是

【解决方案1】：

当我的工作是架构、管理和领导（主要是通过做事；-）这样的层时，我很容易做出决定：一些操作系统（VMS，当时全新的 Win-NT）非常重量级的进程生成（因此它确实需要大量的刺激来生成一个新进程！-），而在另一个极端（例如 BSD 4.3 及其当时全新的vfork！-）肯定鼓励您根据需要生成尽可能多的进程，并且这样做的开销很小。因此，我认为让应用程序程序员决定是否生成是不负责任的——我们（“基础库”组）确实必须提供一个抽象层，该抽象层会根据底层操作系统生成与否。它工作得很好......但也是 15/20 年前，在具有多种操作系统但在内存、内核方面相当统一的禀赋的某一类机器（工作站）上（一个：当时没有多核！ -) 之类的。

如果我今天从事同样的工作，我会首先推动利益相关者（高层管理人员、产品营销人员或其他任何人）明确定义我们必须支持的平台范围——什么操作系统，什么范围（ s) 硬件捐赠。如果 - 正如我所怀疑的那样 - 它的方式与当时一样广泛，那么我的架构在向应用程序程序员隐藏进程产生的概念方面将是相似的。但也许目标范围不同，例如“智能手机和廉价上网本”，这将使选择变得更加困难......尽管从应用程序程序员那里抽象出流程创建是安全的选择，并且只有当您愿意为上述应用程序程序员承担风险时，您才应该公开这一层通用技能以及在您的平台范围内现在可以依靠的任何一致性，在未来保持相当稳定！-)

【讨论】：

感谢 Alex 的宝贵时间。根据您的回答，如果“一个”可以设计一个基于进程的多模块系统，该系统具有用于通用服务的守护进程，例如在单进程多线程架构上的“日志记录”，那么实际上会获得哪些优势？鉴于架构和操作系统有利于这种设计。
@Sashi，多进程具有轻松转换为集群的巨大优势（不仅仅是共享内存机器——内核不断增加，但共享内存的带宽已经无论如何都是瓶颈！-)。如果我现在设计一个新的架构，我会打赌消息传递排除任何共享内存要求，因为这可以解锁无限的可扩展性（和消息传递，到这个抽象级别, 转换为单独的进程 - 您可以实现。如果仍然需要它，作为线程，但是，不是反之亦然...！-)。