在为多模块系统开发操作系统抽象层时,应该采用哪种方法:
- 创建一个操作系统服务共享库,每个模块都被构建为使用它并作为单独的进程运行。或者
- 只创建一个抽象层实例,它提供内存、计时器服务,并且单独生成所有模块实例。
这些方法的优缺点是什么?如果可能的话,还放下任何其他的吗?
在为多模块系统开发操作系统抽象层时,应该采用哪种方法:
这些方法的优缺点是什么?如果可能的话,还放下任何其他的吗?
回到我的工作是架构、管理和领导(主要是通过做事;-)这样的层时,我很容易做出决定:一些操作系统(VMS,当时全新的 Win-NT)具有非常重要的重量进程生成(所以它确实需要大量的刺激来生成一个新进程!-),而在另一个极端(例如 BSD 4.3 及其当时全新的vfork
!-)积极鼓励您可以根据需要生成尽可能多的进程,并且这样做的开销很小。因此,我认为让应用程序程序员决定是否生成是不负责任的——我们(“基础库”组)确实必须提供一个抽象层,该抽象层会根据底层操作系统生成与否。它工作得很好......但也是 15/20 年前,在具有多种操作系统但在内存、内核方面相当统一的禀赋的某一类机器(工作站)上(一个:当时没有多核! -) 等。
如果我今天从事同样的工作,我会首先推动利益相关者(最高管理层、产品营销或任何人)明确定义我们必须支持的平台范围——什么操作系统,什么范围硬件捐赠。如果 - 正如我所怀疑的那样 - 它的方式与当时一样广泛,那么我的架构在向应用程序程序员隐藏进程产生的概念方面将是相似的。但也许目标范围不同,例如“智能手机和廉价上网本”,这会使选择变得更加困难......尽管从应用程序程序员那里抽象出进程创建是安全的选择,并且只有在你愿意的情况下才应该公开这一层冒着上述应用程序程序员的一般技能以及您现在可以指望的任何统一性的风险在您的平台范围内,在未来保持相当稳定!-)