Singularity：对软件栈的反思

在四月版的操作系统回顾（OSR）中，专门单独地介绍了微软的研究项目成果，多篇引人注目的论文（pdf），其中包括了Galen Hunt和James Larus的令人期待已久的关于Singularity的文章，该微软研究项目设立的目的是为了专注于解决如下的问题：

如果一开始就以可靠性为主要目标而全新设计一个软件平台，那这个平台将会是什么样子的呢？Singularity就是为解答这个问题而开设的，Singularity是基于有优势的编程语言和工具的基础上，开发出的一个全新的系统架构和操作系统（Singularity），该系统的目标是为了建立更为健壮和可靠的软件平台。Singularity展示了使系统更健壮和可靠的新技术以及体系结构决策的实用性。

他们发布了Singularity 1.0 版，并向一些大学展示了与他们论文的内容是相一致的研究成果。在无需要考虑如向后兼容这些商业可行性负担的情况下，Singularity具有众多诱人的新特性，这些特性通过新的编程工具和方法论解决了一些典型的计算机领域方面的问题。

InfoQ与Galen Hunt和Jim Larus谈论了Singularity方面的问题。在谈到为何需要这样的一个项目时（除了为研究而研究的原因外），Jim讲到当前其他的操作系统不具有满足下一代用户以及开发者的需求的能力，并向我们解释了Singularity是如何解决该问题的：

现有的操作系统都是在基于以前机器的性能以及使用方式的情况下逐步发展而来的。我们主要的观点是，现在这些系统现处于与它们成长环境非常不相同的世界里，它们需要从根本上改头换面来适应当前世界的需要。大多数大型操作系统的思想都源自于Multics，那时代的机器都在非常低速（100 kHz）和内存非常有限（10 KB）的情况下运行的，那时大多数的程序都通过汇编语言来编写，那时仅通过不同用户间的分时操作来达到文件的安全保护目的，那时网络还没有出现，那时的用户都是有明确的目的且训练有素的。而Singularity是基于当前世界的实际情况，具有快速运算的能力，大量内存的机器，高级的编程语言，久经考验的技术，及无知的用户等的目标而进行设计的 系统。

当问及在众多革命性创新中，哪个创新对于研究社区来说最为重要，Jim讲到：

我并不想只选其中之一，但我认为在Singularity中架构最为重要。我们的目标是通过分离Singularity系统中各构件的耦合，使系统具有更好的健壮性和弹性，而架构正是实现这个目标的缩影。架构表现有多个方面，如微内核，轻量级的SIP（Software Isolated Processes）进程[软件独立进程：独立对象空间，独立垃圾回收机制，独立运行时]，无需共享内存，通过强类型通道进行通信等。

当问到他个人所最喜欢系统的哪个部分时：

我个人而言非常喜欢“进程/通道”设计模式，这模式来自于我早期在分段服务器（Staged Server）上的工作经验，和我所工作的不验证Web Service契约的小组。我认为通道语义（当发送的时，消息的所有权是松散的）很好地权衡了效率，验证和可表达性。

如论文里所提到的，“通道就是有两个端点间的双边信息管道。通道提供无损的，有序的信息队列”。 软件独立进程（SIP）之间使用这些通道进行通信，这与直接共享内存或其它普通的方式非常不同。一旦信息发出，SIP就完全失去了控制权。

所有使用这些通道的通信都必须遵循“通道契约”，该契约与Web Services非常相似，允许系统更高层次的通信验证和使用并行计算（pi-calculus）的形式。Jim讲述到这种形式的好处：

我的小组和Tony Hoare合作的，关于并行计算一致性检验的工作，该工作提供了严密的关于如何去指定和检验通道的某些方面的理论。我们可以提出一些相似的理论，但这会和早期的编程语言中的系统类型一样，如PL/1或Pascal，没有良好的基础来检查它们的正确性。并行计算和一致性检验提供了严密的基础，我们能在此基础上去搭建实用的，有发展前景的系统。

这些增强级别的验证的直接结果是，减低各种系统中通信的缺陷数量，而这些错误通常就是导致缺陷和版本问题的根源。Galen Hunt向我们展示了这样的一个例子：

当我们第一次在代码库运行通道验证器时，我们发现在Web服务器上一个不明显的缺陷。当有一个正在请求的HTTP socket和一个缓慢的客户端时，Web服务器的代码无处理这样的情形。这时候通道验证器会马上进行提示“你的代码不能处理在某某行的无数据信息”。

Singularity用到了许多“新”的编程工具——所谓“新”这个字需要琢磨一下，因为实际上他们已经存在好一段时间了，只是脱离了主流或者是操作系统的领域——其中很大部分与Sing#语言有关。Sing#是另一个非常出名的MSR项目Spec#的派生项目，它是一个基于规范的语言，该语言允许定义前后条件以及对象的不变量，允许通过法则交验器（Theorem Prover，boogie）来检验系统的状态。

状态检验（Static verification）可以查找多种通常的程序逻辑错误，如不恰当的使用一个在编译时而不是运行时的方法。因外界不断的进化要求我们去维护日渐复杂的系统，许多人相信状态检验会变成未来几年的主流。当被问及C#（Sing#的祖父）所提供的状态检验以及使用类型安全环境，是否使到Singularity有令人注目的质量时，Jim谈到：

虽然我们已经积极地使用Spec#，但我们暂时还没有大规模地使用Spec#风格的验证。状态验证器Boogie，逐渐能够胜任系统大规模检验的工作（如驱动程序）。其成果也会非常有意思。另一个我们所依赖的验证（C#类型安全和通道契约）也是非常有用的。他们不会找出所有的缺陷，但是能够有效的防止许多错误。我们看到可以在许多方面对验证进行改进，但同时也感觉受制约绑定新工具遇到的困难。

Galen Hunt给我们讲述了一个关于状态检验的好处的例子：

在春季的时候，我们是推进的SPECweb99 Web服务器基准的主力。我们其中的一个软件工程师Orion Hodson，完全重新动手写了一个全新的FAT32文件系统，该系统使用了Sing#中的所有状态检验的特性。这是到现时为止我们在Sing#验证功能上最大胆的尝试。Orion在上年的冬季是完成了代码的编写，但却没有时间去测试它。当我们热火朝天地在赶SPECweb99项目的那几个月里，我们期望能够找出Orion的文件系统中从未曾测试过的错误，却没有什么进展。我们甚至找不到一个合理的缺陷，没有混乱的情况，没有内存崩溃，什么缺陷都没有。这使到我们确认了强调状态检验来使到系统更为可靠是正确的。

因为Spec#很可能在短期内就成为商用，所以把这些类型的报告记录下来是非常重要的。虽然Singularity到完全商用产品仍需要很长时间，但是它的却为许多由来已久的问题提供了有启发性的的可选解决方案。当问及关于重用Singularity已完成的研究的可能性，并近期逐渐的在商业应用中起作用时，Jim答复道：

我们希望这能成为现实，因为这是MSR目标的一部分。然而，MSR由意念成为正式的产品是一个长期而曲折的过程，所以要花上一段时间，所以这些意念还是难以一时被大系统所接受的。

当问及关于推进这些意念最大的障碍是什么时：

当前系统的向后兼容性。当我们构建新系统时，我们决定忽略这一方面。因这可以给我们许多设计和实现方面的自由，但这也使到现有的产品更进一步地采纳Singularity。我希望通过我上面提到的设计目标，以及高级语言，可以使到项目得到方便的移植。

Singularity在论文中被称为“过程而非终点”，通过别出一格的设计目标，成就了一个出众的原型系统。该原型当然会被以后的研究中用到。虽然缺少如向后兼容这样的商业可行性，假如未来的确如上所说的话，那Singularity则预示了Microsoft未来发布的操作系统的方向。

查看英文原文：Singularity: Rethinking the Software Stack