7 与其它线索模型的比较
7 与其它线索模型的比较 |
|
本章讨论SunOS 多线索（MT）结构和其它商业上可获得的多线索接口之间的相同和不同之处。作为比较过程接口的替代，讨论集中在比较和对比结构上的论点。比较突出了我们所认为的关键的差别，而不是要理解。
Mach 版本2.5 C线索[Cooper 1990],[Trevanian 1987]将线索接口示例化，以提供给程序员一种表达并发性的方法，它独立于底层的系统支持。这是一个必须的特性，但是Mach 版本2.5 C线索没有认识到第二层抽象（例如LWP）的存在，因此不允许程序员控制它所使用的核心资源的程度。在许多有用的应用程序中，程序员必须知道和操纵所要求的实际的核心资源的程度。例如，一个窗口系统程序员必需知道最大可以获得的轻量进程，因为窗口系统可以使用上千个。一个微任务Fortran运行时间库依赖于核心支持的线索，此线索在处理器组上调度。数据库程序员可以要求两种情况的混合。另外，有一方面是核心支持的线索太“重量”，以至于不能输出到轻量进程（例如，虚拟时间），这由应用程序要求。
在Mach 版本2.5 C线索中构造库，以将线索直接映射到核心支持的线索上，或者在核心支持的线索上多路复用线索，但是一个应用在同一时刻不能有两种类型。另外，不能直接访问由核心支持的线索的“重量”特征，因为那将会在线索和核心支持的线索之间仅允许一对一映射。
新版本的Mach [Golub 1990]通过扩充C线索接口，以提供类似我们的两级模型，使得改正了有些低效性。在新库中，C线索在Mach核心线索上多路复用。另外，新的C线索接口允许C线索绑定到Mach核心线索上。
C线索同步原语和SunOS MT结构原语的主要差别是操作的范围。C线索不明显支持使用由mmap内存分配的同步变量，尽管Mach虚拟内存支持在任务间共享存储器。SunOS MT结构支持这个，而且也允许将同步变量放在文件中，以控制对文件数据的访问，并且这样的同步变量的生命周期要比所创建的进程周期长。
C线索支持每一进程的信号状态。没有每一进程的信号屏蔽。没有方法使得一个线索控制它何时处理一个信号，除非阻止进程中的所有线索处理它。当一个特殊线索处在相对于信号句柄的临界区时，它必须阻塞对所有线索的中断。这在繁重异步的应用程序中，会引起严重的性能问题。对于C线索的替代的解决方法是Mach IPC。Mach IPC，然而，并不允许一个计算的异步中断。例如，一个应用程序创建一个线索，以执行一些很长的计算，它会希望无论结果如何都要结束计算。没有方法中断计算，除非将它变成偶尔轮询IPC。这强迫程序员改变计算代码，使得经常做轮询，以满足响应终止请求，但不过于频繁以减慢计算。
Chorus[Armand 1990]打算避免用户级的线索，因为感觉到它会影响实时性的要求。例如，两级调度接口要求最高优先级可运行的线索总允许运行。SunOS通过允许线索绑定到一个LWP上而获得一个系统范围的调度优先级，来满足这个要求。另外，此绑定线索可以要求底层的LWP作为实时调度类的一个成员，以提供更准确的调度控制。
Chorus线索中的每一个有一个信号屏蔽和一个信号句柄向量。计算接受一个异步产生的信号和将缓冲SIG-DFL和SIG-IGN相结合的影响。如果一个或者更多的线索缓冲此信号，将它递交给所有的缓冲线索（广播递交）。否则，任何线索设置句柄为SIG-IGN，丢弃此信号。否则在进程上做缺省的动作。这个模型的主要的低效率是当处理线索试图同步时，广播递交会引起“同步风暴”。它也引起核心的额外的工作。最后，广播使递交给进程的许多信号在非队列信号实现中不可计数。例如，如果几个线索正等待一个键盘中断，而且两个被发送，那么有些线索将接受两个信号，而其它接受一个。
每一线索信号句柄增加一些代码粒度，要花费处理如上所提的SIG-DFL和SIG-IGN的复杂性。所增加的代码的粒度相对是较少的。因为异步信号多数由应用程序控制，而不是库。另外，系列处理一个线索的同一信号仍是个问题，如同在单线索的UNIX。
由华盛顿大学[Anderson 1990]开发的Topaz[McJones 1989]操作系统的变形，实现了带有轻量用户级线索的可移植线索接口，此用户级线索按需求使用核心资源。在多数情况线索可以同步，而不用核心的介入，同时，I/O、缺页错以及其它的阻塞操作不停止整个进程。此方法与我们的线索在LWP上多路复用有同样的优点。然而，它不支持程序员控制核心资源的使用。
华盛顿大学的工作和SunOS MT结构的主要基本的差别是华盛顿大学使用轻量“调度者激活”，它上调用户空间，以将可调度的执行上下文提供给线索包。无论当前在核心中进程块何时使用调度激活，由一个新的调度激活所产生的上调通知线索包。这给线索包以调度另一可运行线索的机会。这相似于我们结构中新的SIGWAITING信号的功能。这个信号也给线索库机会，通过第一次创建一个新的LWP，来调度可运行的线索。主要的差别是当前SIGWAITING的定义比调度者激活所使用的方式更粗。前一个仅当LWP阻塞在一个无定义等待时才发送，而后一个在无论何时因任何事件线索阻塞在核心中时都发送。在将来，我们计划试验在“更快”的事件上发送信号。
华盛顿大学的方法对于在处理器上调度线索，给与了更多的细粒度控制，尽管并不清楚这是一个绝对的需要。一般地，SunOS MT结构满足作为华盛顿大学校目标的大部分要求。二者都很重要地感觉到核心不必嵌入到每一线索操作。
比较POSIX P1003.4a Pthread [POSIX 1990]在此时有些困难，因为它是一个正在移动的目标。目前（pre Draft 10)，看起来信号模型是SunOS模型的一个直接的超集。另外，在调度接口中看起来由对两级线索模型的支持。然而，忽略了同步变量和映射文件的支持。(P1003.4)
在SunOS 4.0中提供的Sun LWP库[Kepecs 1985]是一个经典的用户级线索包。它不包含明显的核心支持。线索（称为LWP）彼此同步，而不用核心的介入。如果一个LWP调用一个阻塞系统调用或者发生缺页错，整个应用程序阻塞。通过使用非阻塞I/O库而不是标准的UNIX I/O接口，可以缓和它。非阻塞I/O库使用核心支持的异步I/O设备，以模仿标准的I/O接口，而且当一个线索阻塞在一个无定义的I/O上时，允许包切换LWP。当发生一个缺页错时，应用程序仍然阻塞。
SunOS对线索体系结构在功能上完全是此接口的超集。
| Copyright: NPACT |
|