ACM通信

研究突出了

技术视角:决定论的实验

史蒂文手
ACM通讯，2012年5月，第55卷第5期，110页
10.1145/2160718.2160741
评论

多核处理器的出现意味着复杂的软件正在变得更加复杂:开发人员必须转向使用多线程来利用硬件的并行性，然而，人们普遍认为并行编程比编写顺序代码困难得多，也容易出错。特别是，无数允许的线程执行交错意味着程序的不同运行可以产生不同的行为，包括不同的输出或更糟糕的bug !

为了解决这一问题，最近人们对确定的并行性:确保程序的多次执行遵循相同的交错的技术，而不管硬件的变化，调度程序的变化，同步原语的使用，或外部工作负载的存在或不存在。我们的希望是，确定性并行将使测试软件质量更容易有信心:例如，如果一个bug可能是由于对内存中对象的特定读写顺序造成的，那么确定性并行将确保这一点总是因此，更容易调试和确保它从来没有发生了，完全避免错误。

以前的一些工作研究了在语言(确定性并行Java)中提供确定性的并行性，在编译器和/或运行时系统(Kendo, CoreDet, dThreads)级别，或在硬件(DMP, RCDC)。这些方案中的大多数并没有使并行编程本质上变得更简单，而且大多数方案仅限于多线程(而不是多进程)系统。然而，在接下来的论文中，Aviram等人探索了构建一个操作系统这在所有托管程序内部和跨程序之间强制了确定性的并行性。

大多数传统操作系统提供的接口都是不确定的;例如，用创建一个新进程fork ()或者用open ()产生依赖于之前在系统范围内或当前进程内执行的操作集的句柄;在内存分配中也可以看到类似的行为。这些值可以直接或间接地影响控制流和一般计算，从而导致不同的行为，即使没有显式的“竞争条件”。当然，显式的非决定论经常通过诸如wait ()对进程或条件变量，或调用select ()一组文件描述符。

为了避免这样的问题，作者采取了一个全新的方法与他们的限定词操作系统。在Determinator中，每个独立的执行线程获得一个私有的工作空间，而不是线程共享一个地址空间。这是一个复制线程的所有读和写操作都直接在副本上执行。在线程退出器的某些其他定义良好的点，线程执行的效果与全局状态一致。这可以被认为类似于现代版本控制系统的操作方式:一个人“签出”数据的私人副本，进行他或她希望的任何更改，然后“签入”这些更改。私有工作区的使用消除了细粒度交错所涉及的任何不确定性;实际上，读/写数据竞争是不可能的，因为任何线程只会读取规范的值，或者它自己写的值。

然而，就像修订控制系统一样，写/写冲突是可能的:两个子线程可以在执行期间修改相同的(逻辑上共享的)位置。在Determinator中，这很容易在协调阶段确定，并导致运行时异常。作者认为，将写/写冲突转变为容易重现的bug可以简化编程模型，并避免对“良性”数据竞争的任何依赖。

限定词还控制着非决定论的其他方面。例如，内核返回的标识符是线程私有的而不是全局的，所有的同步操作都是确定的，而不是先到先得(就像许多互斥锁一样)。这将导致系统具有与传统操作系统完全不同的“感觉”，但作者证明了运行许多并行基准测试程序而没有任何不良影响是可能的。它们还描述了一个模拟层，该层提供一些熟悉的Unix api，尽管偶尔会有不同的语义。一个很好的例子是进程同步的实现;而WAITPID ()可以很容易地支持，非决定论的WAIT ()不能。而不是WAIT ()变成“等待具有最低(线程本地)进程id的子进程”，在许多情况下，这就足够了。

决定因素是一个有趣和发人深省的研究。然而，目前还不清楚未来的操作系统是否会以这种方式构建。在如何支持I/O操作方面存在许多挑战，特别是那些与用户或远程系统交互的操作;以及如何支持固有的不确定性计算，例如生成加密密钥。

这不仅仅是决定因素的限制，而是该领域大多数工作的限制。尽管确定性并行有可能减少程序(或系统)可以表达的允许行为的数量，这应该会提高测试的效率，但它不能帮助大多数有用的程序在给定不同的情况下表现不同的事实输入．依靠大量的测试来验证程序的正确性在智力上是不令人满意的，特别是考虑到所获得的不幸的不充分的覆盖，以及任何规范的普遍缺乏。尽管如此，决定论并行化还是有可能让这一切变得简单一点，这不可能是件坏事，不是吗?

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2012 ACM股份有限公司