venus

The Venus system was a small timesharing system serving five or six users at a time:分时系统

The design of the Venus operating system. Barbara H. Liskov (1972)

Although it broke no new ground, the Venus system was another convincing demonstration of Dijkstra's concepts of semaphores and layers of abstraction.  Dijkstra关于信号和抽象层次的观点。

venus操作系统是一个实验性的多道程序设计系统Multiprogramming ，在一个小型电脑上支持五六个并发用户。这个系统用来测试机器架构在软件复杂度上的效果。这个系统的定义是微程序和软件的组合。微程序定义的是有不寻常的架构特色的机器，软件尽可能简单地利用这些特征定义操作系统。这篇文章描述了这个系统的发展，着重介绍了指导这个设计的原则。

关键字和词语：操作系统，系统设计，抽象层次，机器架构，微程序，段，信号，多道程序设计  ，虚拟机，进程，进程通信，虚拟设备，数据共享，资源管理，死锁。

介绍

      venus操作系统是对小型计算机的实验性的多道程序设计系统。支持五六个在线和交互式地电传的并发用户。它也许和其他的多用户系统不同，它首先迎合互相合作的用户，例如，一组用户共享数据基础或者建立由合作的进程构成的系统。

这个操作系统是用来测试下面的假设：如果这个系统建立在有正确架构的机器上，建立系统的遇到的困难可以很大减少。我们想要一个系统，他的数据和进程需求动态变化，例如操作系统或者在线数据管理系统。我们发现目前可利用的机器不能很好地支持这样系统的设计，为配合硬件的不足，软件的复杂度很高。

首先，有必要建立一个有正确架构的机器。这个在interdata 3计算机的微程序已经做好了，叫做VENUS机器。这个微程序包括一些耗时的和复杂的任务的解决办法，这些任务由这种系统和建立这些系统的有用的机制产生。

下一步，有必要把venus机器用在软件应用上。一个操作系统被选择作为最初的努力，因为它是这种机器打算支持的系统，因为它可以提供设施可以支持后面的应用。

系统设计原则

      设计操作系统的两个主要原则如下:

1.dijkstra定义系统被构建作为抽象层次的等级。希望这样可以带来更高的透明和更少的错误。一个层次不仅被它所支持的抽象定义，例如虚拟内存，也被用来实现抽象的资源定义。低层次（靠近机器）不知道高层次的资源，高层次只能通过调用低层次的函数来应用低层次的资源。这样减少了系统部分之间的交互、使系统部分之间更清楚。发生在微程序和软件中的抽象层次的例子，贯穿本文。

2.venus机器的特点被允许影响操作系统的设计，为了估计在软件的发展上的架构的影响。

指导操作系统设计的几个其他的原则

3.性能的效率

4.保护独立的用户，限制对合作的用户或者组的错误影响

5.给用户尽可能多的入口进入操作系统developed产品特征和软件机制

首先考虑两个主要的原则。下一部分讲了venus机器的特征在操作系统上的most影响。下面讲了这些特征是怎么扩展去支持操作系统的设计。然后是资源管理设计。最后是设计经验。附录是用户看这个系统的眼光，试图通过这个系统怎么支持用户实现他的工作，来解释清楚本文的抽象观点。

venus机器

硬件

built by Interdata 3，一个小的，慢的，便宜的机器。微程序存储在只读内存，不超过2000个，在它的内容上强加了相对严格的限制。Interdata与几个打字机、一个读卡器、一个打印机、两个磁带相连。另外，有一个小的分页磁盘，内存为50万字节。这个磁盘和磁带通过hardware selector channels有直接的存储通道，其他设备一次传输一个字节。

微程序

除了传统的指令集系统，Venus支持很多不标准的架构特征。本文介绍了最主要的特征：段、16个并发进程的多道程序设计、一个微程序的多路复用I/O通道、程序。

段。段是虚拟内存，每个段包含最大64000字节，15bit的名称。段是venus系统的主存储器。段和核心存储器都是分为256字节的页面。每一个核心存储页的信息保存在一个单独的、集中的常驻内存的表中。核心页表core page table,用来表示虚拟地址和真实地址的映射。给定的虚拟地址的引用会被映射到相同的真实地址，这就是说，进程之间在物理上共享段。另外，一个进程不能阻止另一个进程访问段。这个约束是有意义的，仅因为venus机器是设计用来支持由相互合作的进程组成的系统。

venus机器需要分页Paing。如果微程序不能在core page table上定位所需段的页，会启动一个软件例程software routine，页错误例程page fault routine从磁盘上获取页。page fault routine像是微程序的一个子程序，当需要和返回时通过一个特殊的指令被微程序调用，to the microprogram at the point where the page fault was detected.

多道程序设计系统Multiprogramming。一个进程是在虚拟机上执行的一个程序。venus机器支持16个虚拟机，每个包括一个地址空间和工作区域。地址空间包含所有的段，所有的进程是一样的，不过对特别的进程只有几个段是有意义的。工作区域永久保存在内核，包含150个字节的进程相关的信息，包括通用寄存器，程序计数器，和其他关于进程状态的信息。

　   进程的CPU调度由微程序执行，让我们能够定义一个独立统一的机制通过进程间处理器的控制。这个机制甚至用来指出i/o端。This mechanism, used even for indicating the end of I/O,is provided by semaphores,Dijkstra第一次这么定义。信号用来控制资源共享和同步进程。信号量有两个操作，P,V。P表示进程等待一个事件发生或者资源可用。V表示释放资源。

Dijkstra定义信号量是一个整型变量和一个相关的等待列表。Venus中，等待列表用队列表示，定义一个信号量是一个有序对（count，link）来表示联合。count是负数，表示等待队列中有的进程数。这种情况下，link指向最近执行P操作的进程的工作区域,那个进程的工作区域是一个指向队列中下一个最新进程工作区域的指针，等等。并且在每个进程的工作区域有一个优先级，可以用软件设置。当要队列中移走一个进程时（因为执行了V操作），优先级最高的进程被移走。如果最高优先级和多个进程有关，选择在队列中最久的。

venus中的进程调度只会以进程间或者I/0通道的P、V操作的结果出现。Venus中所有的进程都处于三种状态之一：一个独立运行的进程，准备运行的进程，阻塞进程。就绪进程排列在一个特殊的队列，J队列。阻塞进程在与信号量有关的队列。如果运行进程执行了P，请求不可用的一个资源，或者等待一个没有发生的事件，就变成了阻塞态。同时，J队列优先级最高的、最老的进程变成新的运行进程。如果执行了V操作，一些阻塞态的进程也许变成就绪态。如果这个进程的优先级低于正在运行的进程，会被添加到J队列，否则，会变成运行进程，原先的正在运行的进程被添加到J队列。正在运行的进程的优先级总是至少高于所有的就绪进程。

I/O信道。microprogrammed微程序控制的I/O信道释放软件不受实时约束，这个约束与满足设备需要的I/O传输增量规范有关。microprogram微程序的运行信道在指令的执行之间，从软件的角度看，信道运行与执行运行同时。信道通过执行位于进程开始转移的工作区域的一个V的特殊信号表示I/O的完成。当进程要同步I/O时，在这个信号上执行P。

程序。每个程序存储在一个特殊的段。call和return指令把进程从一个程序的指令转换到另一个程序的指令。参数和值可以在一个被用作下推堆栈的特殊的段中传递，其中引用了push和pop指令。

在venus机器上，共享程序是desirable。当然，只有可重入的程序可以被共享。最初支持可重入的程序来自单独的虚拟机。call、return、push、pop指令提供了可重入程序的接口。而且，没有简单的存储程序的方法，无论何时需要时，段提供了私有的临时工作空间。

抽象层次

抽象层次的设计原则应用在软件中，也应用在微程序中。微程序支持的层次和缺页处理包括虚拟内存抽象，虚拟机抽象和真正支持虚拟设备的I/O信道，例如，一个读卡器一次读一个完整的卡。图1说明了与这些层次相关的appeal的资源和方法。

抽象	资源	Method of appeal
段	核心页表，磁盘（disk）	段引用，elf指令
虚拟设备	设备，设备状态字表	Sio指令，通道命令
虚拟机	J队列，处理器	PV操作

 Venus机器的扩展

第二个主要的设计原则是用Venus机器的特征影响操作系统的设计。因此，我们希望这个系统用段存储数据，由可再生程序和异步进程组成。可以通过研究这种结构怎么应对系统执行工作最方便的方式获得这种结构的好处。

我们对设计一个支持多用户的系统感兴趣。每一个用户分配到一个独立的虚拟机，因此由一个独立的进程代表。为了支持这些用户，这个系统必须执行某些任务。一些任务很自然地通过可再生系统程序在用户的虚拟机上执行，使用段保存用户相关的数据。其他系统任务在逻辑上与用户异步（例如，running I/O devices for the system as a whole在这个系统上运行I/O设备作为一个整体）。这些任务可以在物理上异步通过分配给他们独立的进程。因此这个系统做的工作可以在进程中分配，这样逻辑上并发异步的任务可以通过物理上并发异步的进程执行。这样可以清晰地设计。

为了让venus机器更方便地使用，在软件中定义了几个抽象的层次。两个层次描述如下：第一个，字典，支持段的方便使用，第二个，队列，支持进程间的通信。

 字典

构建一个系统没有包含程序和数据的段需要段之间的交叉引用。venus机器支持通过内部段名 对段的引用，这样不方便程序员使用和记忆。而且，内部段名是动态分配的（通过缺页处理器），程序员需要一个静态的名称。因此，引入了外部段名。

为了支持外部段名，需要内部名称和外部名称之间的映射。这个通过字典提供，字典存储在段中。外部段名实际上是一对符号名称：符号名称附属于段，字典的符号名称应该被用于执行这个映射。一个特殊的字典包括所有字典的符号名称和外部名称的映射。这个二级外部名称允许相关的段组合在一起（通过相同的字典引用），并且让用户更容易得到一个独特的名称。

虽然字典最初是为了支持外部段名，但是字典实际山是一个通用映射工具，偶尔被系统这么使用。

队列

异步进程之间也许也需要发送和接受信息。P,V允许进程等待或者作为事件发生的信号，但是不包含任何关于这个事件是什么的信息。一个进程也许在等待几个不同的事件，它必须知道哪个事件发生从而执行合适的操作。需要一个允许一个进程发送信息，这个进程和其它的进程接受收的机制。选择队列来实现这个目的，因为队列提供一个按时间排序的元素。所有的队列保存在一个独立的“队列段”，特定队列的头在这个段中的位置通过相关的"队列字典"获得。

资源管理

一个操作系统必须管理机器上的可用资源，这样可以避免死锁并且资源可以公平地分配给用户。这里相当详细地描述了venus的资源管理，部分是因为这是操作系统的一个有趣的部分，并且部分作为使用抽象层次和进程间任务分配的使用例子。资源管理主要由独立的进程同步和互相通信提供。

如果几个进程自由竞争资源，可能会产死锁。死锁最简单的例子是：

进程1拥有资源A，等待资源B。

进程2拥有资源B，等待资源A。

进程1和进程2都不能继续。我们想要避免venus操作系统的死锁，需要对资源管理做仔细的设计。被软件管理的资源包括段和i/o设备，核心，分页磁盘，cpu被微程序管理。虚拟机也必须被管理，但只是在没有更多可以分配给用户的意义上说。but only in the sense that no more can be assigned to users than are available.

共享数据段的管理

共享数据段的管理是复杂的因为确保不会发生死锁的通用解决方案会阻止用户运行,即使情况是完全安全的。在我们的系统中，用户必须控制用户定义的数据段的共享。信号量为用户提供了一个工具去控制共享通过用户自己选择的算法。如果这个算法不能正确工作，只有这一组的用户会被影响。

仍然有系统数据结构的问题，这个系统数据结构也提供给用户，例如字典。字典是为了共享，同时也可能被引用。当字典被改变时，它不包括一致的数据，因此这里需要互斥。与每个字典有关的是一个用来控制共享的信号。字典访问可能只能通过调用特殊的可重入词典程序,在适当的地方在相关信号量上执行P,V操作。限制字典访问这些程序保证了信号量会正确使用(例如,每个P最终会跟着一个V)，而且不会出现访问错误。访问任何共享系统数据结构(队列是另一个例子)总是被一组程序限制。这一组包含一个抽象层次，拥有访问段作为一个资源。

I/O设备的管理

所有的I/O设备的管理是类似的。系统保持设备的所有权，用户能访问确定的限定的事物，保证不会发生死锁。这部分讨论了怎么管理设备，下部分解释抽象层次怎么被用来完成管理。

打字机。我们的系统是在线的，交互的，因此每个用户需要一个打字机。一个解决方案是分配给每个用户一个打印机让他可以单独使用。这需要一个打印机作为指定的操作控制台并且控制方式不同，因为系统偶尔需要一个打字机通知特殊的条件和错误。而且，对于一个用户给另一个用户的打字机发送消息，或者对于一个系统这么做，是不自然的。

选择的解决方案是定义一个用户开始运行时的打印字作为他的首选打印机。他可以象征地引用这个设备，并且通常将使用它，但是用户不被限制这么做，并且不能阻止其他用户使用它。一个打字机可能不被中断有足够长的时间被访问去写然后读取一行。这样保证打字机的标准使用，用户（用一个命令）对程序做应答，被告知这么做时，可以不受其他用户的中断。

其他设备。读卡器，打印机，两个磁带的需求都很高。因为磁盘小，符号数据只能在有限的时间内在内核和磁盘存储器中维护。读卡器和磁带提供了唯一合理的方式访问大量符号数据，只有在磁带上，被编辑的符号数据可以被保存然后被读取。打印机提供了唯一合理的方法列出符号数据。用户每次运行时很可能需要长时间访问这些设备中的几个。

当系统保留控制时，所有的用户收益，保证设备有效地运行，并且只要有工作做，设备会保持繁忙。为了用户方便，设备也许在相当长的时间内不被中断得访问，例如，足够长的时间列出用户程序的装配或者在用户的卡片组读卡。

抽象层

系统通过提供给用户虚拟机执行设备管理，虚拟机与真实的设备有很大不同。通过几个抽象层完成，分布在几个进程中（见图2）。

0层，由微程序提供的设备，没有实时约束，但是需要内核缓冲区。1层由软件控制器组成，每个设备一个。每个控制器是一个独立的进程（虽然一个可再生程序可能作为几个控制器）。控制器支持的虚拟设备有下列特征：

1.只可能有几种类型的转移，例如，只有一个卡可读。Only a few types of transfers are possible, for example, exactly one card may be read.

2.用于转移的缓冲区位于段中。

3.设备转移的请求可能发生在任意时间，不管这个设备当前是否被使用。当这个设备可用时会被执行。

4.转移完成的标志是转移请求的信号量的V操作的执行。

在控制器层之上，打字机的控制和其他设备很大不同。

打字机。一个可重入的程序，打字机请求程序（2层）控制打字机。首先它提供了一个用户和控制器的接口，在用户的虚拟机上运行。

其他设备。打卡器，打印机，磁带可以被大量数据访问，远超过控制器可以接受的数据。驱动（3层）支持这个抽象。每个驱动控制一个设备，是一个独立的进程。支持的特征是：

1.设备一次访问一个段。驱动把段分成可接受的缓冲区给控制器。

2.The Driver defines the type of synchronization required.驱动程序定义了同步所需的类型。无论什么时候送料斗有卡there are cards in the hopper，读卡器驱动构建段包含卡片组的意象。只有要获得完整的段时需要用户同步。打印机驱动需要被通知一个段要被打印，无需与打印的完成同步。磁带驱动器需要被通知在磁带上读或写一段，用户必须等待它的完成。

以上每个驱动是一个请求者（4级），主要提供用户和驱动间的接口，运行在用户的虚拟机上。这些请求者比电传打字机请求者更复杂。例如，打印机请求者帮助用户生成可打印的段，而磁带请求者是一个交互式程序，在用户命令上读取和写入磁带上的段。

总结

两三人年构建机器，估计六人年设计和应用系统（包括公用功能，例如汇编程序，编辑器，调试辅助工具，以及操作系统功能）。

此外，抽象级别的使用是有价值的工具，因为它提供了一种思维方式关于清晰度与精度设计。当把系统放在一起时，错误暴漏了。但大部分忠实地遵循的关于资源的所有权的规则，最小化的系统部分的相互作用所引起的错误。如被发现从内部的一些片完全未签出该系统的误差和误差追溯到打破有关资源规则导致此类错误。抽象级别的一个额外的好处是的方便，可以修改该系统 ；它的设计被分层的拟议修改的影响都清晰可见。

Appendix--A User's View of the S ystem
     The user views the system in two ways. First, he must write his
programs; for this he is interested in available data structures and
system procedures. Then he is interested in running and debugging
his programs.
Programs running under Venus use segments for all storage--
procedures, data, and pushdown stacks. Because segments are available
by external name through dictionaries, users can readily share
data and procedures. Users may also synchronize with other users
through queues and semaphores.
A user runs on-line and interactively. He starts up by typing a
command on a teletype and is assigned a virtual machine under the
control of an interactive system procedure called the Loader. The
Loader recognizes many commands; the most important is the "E"
command, which passes control to a specified system, utility, or user
procedure. Important system and utility procedures are the Assembler,
Editor, Tape Requester, and Debugger.
The user submits card decks to be read prior to his run; he may
access all decks through a command to the Loader. The names of
the segments containing the card deck images are entered in a dictionary
associated with the user. The user may read segments from
tape; the names of these segments are also entered into his dictionary
where they may be assembled or edited on command. Binding of
intersegment references occurs on completion of assembly.

The user executes procedures by giving the "E" command.
Execution can occur with or without debugging; no change to the
procedures being run is required. Debugging is handled by an
interactive system procedure which runs before the execution of
every instruction and can be used to stop execution at a specified
"breakpoint." A dialogue with the user then commences in which
the contents of a segment or his work area may be displayed and
modified, a new breakpoint specified, and control returned to the
interrupted procedure or the Loader.
The system also provides interactive interrupt procedures which
run as the result of exceptional conditions, for example, a stack
underflow or overflow. They make use of a subset of the debugging
commands, permitting the user to discover the reason for the error,
restore his data, and return to the Loader.
When the user has finished running he saves his symbolic data
on tape and then informs the Loader, which releases his virtual
machine and destroys his symbolic data. His checked-out programs
may be entered in the system and become accessible to others
through dictionaries.

可重入http://baike.haosou.com/doc/6084295-6297397.html