CN1189227A - 计算机系统的启动系统 - Google Patents

Abstract

一种综合计算机系统的程序系统是很用户专用化的,因此启动变化很多。因此一种这样的计算机系统的启动系统必须是很灵活的。另一方面对该综合的启动的及时和严密的监督仍然应该是得到保证的。这些要求通过一种启动系统来满足,它具有脱机地以按本发明的方式生成的启动表。

Description

计算机系统的启动系统

在复杂的计算机系统，例如交换系统，启动(恢复，Recovery)的情况下，必须有众多的处理机和大量的软件(这就是说计算机系统的程序系统)投入运行。因为综合计算机系统的程序系统在很大程度上是用户特定的，所以各计算机系统的启动有很大差异。

因此，迄今动态地生成用於确定用户特定启动的起动表格。可是，由於这种动态生成，在早期的时间点上设计这种启动是不可能的。除此之外，在表格联机地完全建立以后，才能识别各单项软件部分之间的依赖关系。

因此一方面期望获得对启动整个过程的及早的和较强的检验，而另一方面还使启动保持灵活，这就是说对不同的用户特定的设备程序系统是保持可变的。

此外整个系统的启动应可靠和快速地进行。

本发明的任务在於满足所述的要求。

该任务通过按权利要求1的启动系统来解决。

通过表格的静态生成，使得有可能对启动的整个过程及早地和紧密地检验以及保证可靠的和快速的启动。

通过及早的检验可能性，已能够於联机测试阶段之前，也就是已经在实时系统的实际启动之前，通过相应的工具(Tools)来发现和纠正差错(例如死锁)。

通过各自在同一软件成分(Software-Komponente)中说明一种软件成分的启动关系(启动信息)，在静态生成的启动表格(Start-Up表格)中，每次仅考虑了在用户特定程序系统中当时存在着的那种软件。

此外，由此促进了启动的细微的模块化，并且因而促进了软件成分池(SW-Komponenten-Pool)相对於变动和/或扩充的独立性或灵活性。

最后，通过在软件成分中说明启动关系，使得介於启动软件的各部分之间的依赖关系已经在本来的启动之前，变得明显起来，从而简化了整个启动过程的设计。

通过权利要求2说明了本发明的一种实施形式。按本发明的该实施形式，在一种软件成分编译之后，已经存在着一种在设计的时候已能检验的部分表格，它经过一种相应的工具使其变得是可见的。

本发明的一种实施形式是通过权利要求4来说明的。通过该实施形式能够在表格内确定，是否应进行跨越平台的同步。由此有可能定义跨越平台的、在全系统中或在系统的部分中的系统状态。因此在一种平台上等候由另一种平台准备好的系统状态。用另外的方式来表达的话，这意味着，在实时系统不同的计算机上，软件的不同部分之间的从属关系，从此以后已经可以在设计的时候以简单的方式加以考虑。

本发明的一种实施形式是通过权利要求5说明的。针对用户软件的启动，通过该实施形式变得比迄今的从根本上更精细和更灵活。只有当用户软件与启动有点关系时，它才运行。启动由此变得更快和更稳定。

下面借助於附图详细地说明本发明的一个实施例。

首先对在下面经常采用的术语进行解释。

启动(恢复，Recovery)。

为了在出现差错和断电之后以及在投入运行等等情况下，建立一种适合於设备程序系统的软硬件状况的措施。

设备程序系统(APS＝应用程序系统)：

一种设备程序系统包含在一种计算机系统中，例如在一种交换站里，所需要的全部程序和数据(实时系统的原装程序除外)。对每一种综合的计算机系统，需要一种独特的，这就是说针对有关计算机系统的使用特点而设置的设备程序系统(用户专用的APS)。设备程序系统是以机器语言表达的一种已经受约束的程序系统。

服务模块，外壳：

在程序语言层面上以模块方式构成软件。互相处在紧密关系中的模块，以Chill语言汇总在较大的软件成分，所谓的服务模块(服务准备单元SPU)中。该SPU是每次由编译程序翻译的软件单元。外壳是可装入实时系统的、和在设备程序系统的运算时间中、通过构件从服务模块中生成的那些软件单元。

软件成分池：

软件成分池包含(源-码-)软件成分的总和，从这些成分中每次编译和汇总一部分，以生成用户专用的APS。

启动控制程序：

启动控制程序控制着启动，和在以下也称作为启动(Start-Up-)控制程序(简称SUPO)。启动控制程序包括一种以操作系统模式(管理状态)运行的启动部分(SUPO_SYNC)，和一种以用户模式(使用状态)运行的和作为过程实施的启动部分(SUPO_PROCESS)。

首先对本发明作简要说明。

本发明的根据在於，一方面获得对启动整个过程的及早的和紧密的检验，另一方面使整个过程保持灵活，这就是说不受用户专用APS性能的影响。

为了解决该任务，整个软件生产(SW-Produktion)被一体化到新的启动方案中去。还在设计的时候，软件开发者就必须以与其它同步点和应实施行动的关系(条件与量值)的形式来说明各SP。在由开发者每次设计的软件成分中进行这些说明。

通过该编译从各SP-说明中生成一种部分表格。

在用户专用设备程序系统的生产时间，通过将软件成分连结起来，使这些部分表格最终联接成一种分类的表格(从逻辑性观点看，形成一种单一的表格)。按照在软件成分(服务模块或更确切地说在其中包含的模块)中所说明的与其它各SP的关系，借助於一种专门的工具进行这种联接。

启动控制程序，然后在这些脱机生成和联接的表格上存取，以便按照包含在表格中的启动信息来执行启动。

借助於脱机生成的启动表格，就有可能保持启动控制程序不受设备程序系统性能的影响。如果启动本身应获得新的性能，由此只剩下必须改变启动控制程序。

针对设备程序系统而言，启动控制程序却是完全独立的。该独立性很简单地产生於以下情况，由设备程序系统的各单项成分本身规定启动同步信息和脱机地列入启动控制表格。

通过该启动，一种实时系统逐步地被启动，在此情况下每一步代表一种稳定状态。这些状态以下也称之为同步点。它们中的几种只有局部的意义，而其它又具有遍及整个系统的意义。其意义的范围完全取决於同步点所处的说明级。

图1展示一种典型的交换系统的启动段的(层次)级，即一个系统级、一个功能级、一个应用级和一个用户级。

在利用完整的表格的，即利用所有的启动段的情况下，进行设备程序系统的启动。在启动段的不同层次级上，说明的立足点是各自不同的，这意味着在最高的级上启动段仅仅是很普通地说明整个系统，而且越进入往下的层次级里，说明就越详细，可是在每个启动段中所说明软件的数量就越减少。在最低的级上仅还说明SPU的各单项过程的互相配合，但是全面地说明此互相配合，这意味着人们在此可以识别各单项过程之间的关系。

在系统级(级1)中说明在启动时各单个软件功能复合体的互相配合。该级包含整个设备程序系统启动的同步点。这些同步点表明一种源网格，其余的软件存入其中。

功能级(级2)说明有关系统主要功能复合体的成分的启动，例如硬件维护、软件维护、CCS7，它们同样具有全系统的意义。

应用级说明功能性成分(有几种总还具有全局性意义)的启动；在CCS7的情况下可以举出信令管理者SM和信令链路终端SLT作为用於这种功能性成分的实例。

进程级(层次级4)说明以下也称之为用户软件的设备程序系统进程软件的启动。应用数据库ADB、高性能数据库HPDB和协议处理程序管理者(PRH Manager)可以称之为进程级成分的实例。

软件成分的每一个启动段包含一个同步点的清单，在此每个同步点主要包含启动信息(关系信息)的两种等级。

在关系信息的一种等级中涉及的是所谓的“动作”。一旦由同步点表达的系统状态已实现时，这些“动作”表示对那些必须执行的动作所作的说明。

在关系信息的另外的等级中涉及的是必须满足的“前提”。

介於各SP之间的关系各自包含两种组成部分：1)一种部分，它在一种SP中说明该SP(一种SP)向另一种SP提供量值，和2)一种部分，它在另一种SP中说明该SP(另一种SP)必须等候这一种SP的前提。

如果应定义例如介於两种SP之间的关系(SP_x和SP_x)，在此SP_x必须在SP_y之前被实现，则对该关系有两种组成部分：1)在SP_x处存在着，SP_x应向SP_y提供一种量值(此事存在於SP_x的“动作”中)。2)在SP_y处存在着，SP_y必须等候SP_x的一种量值(此事存在於SP_y的“前提”中)。

关系信息(动作与前提)的两种等级包含一种混合体：它们包含针对过程的部分和针对段的部分：1)动作：a)段-组成部分：

-对其它各SP的基值(Kontributionen)b)过程-组成部分：

-过程的启动

-继续进行被延期(被暂停)的过程

-通告过程(用消息)2)前提：a)段-组成部分：

-“等候”来自其它各SP的基值(Kontributionen)b)过程-组成部分：

-“等候”来自过程的基值

通过位於一种同步点定义内部的相应语句，来定义对其它同步点的关系信息。

为了避免介於启动段之间的过於复杂的关系结构，在一种段中所包含的各SP，允许只涉及具有最多为一层次级级差的其它段的同步点。

为了将由操作系统管理的，在以下也称之为用户过程的过程并入启动，用户软件编程者，首先同样在一种包含该种或这些应并入过程的服务模块中，定义一种或多种起动段，并且通过相应的连结语句(关系语句)将这些起动段与应用层次级的启动段相连结。此外用户必须规定他的过程对用户启动段的关系，其方法在於，他申报他的过程，在此这些申报信息是各自涉及一种SP的。申报信息包含着说明，利用用户启动段之一内的那个同步点，来启动用户过程和过程为那个同步点提供量值。位於过程级上的所提及的申报信息以后将详细说明。

在接着详细说明通过SUPO来利用启动表格之前，以下将详细说明启动表格的结构及在其中包含的信息。

图2展示在一种处理器之内的启动表格的结构。

启动表格是被分布在一种处理器的整个软件平台上的，在此每种服务模块SPU包含启动信息中的从与启动的关系看对该服务模块是重要的那种部分。

通过在所谓的“外壳-逻辑程序设计语言(Kapscl-Prolog)”中的和在“SPU-Prolog”中的地址信息进行对启动表格的存取。启动表格的一段包括所谓同步点单元(SP-单元)，在此每种SP-单元代表段内的一种同步点。一种SP-单元又包含对与该同步点相连结的“关系”的说明。图2示范地展示包含三种同步点的一种段(段y)是如何在启动表格中被代表的。

以下详细说明在启动表格中所包含的启动信息。

如同前面已说明的那样，启动段是启动表格中那种包含原来启动信息的，即包含位於所谓SP-单元中同步点信息的单元。

以下的程序语言工具，更确切地说数据结构，可以用来说明(定义)启动段：

一种用于定义段的等同性的数据结构“段名”。该结构包含外壳标识符(外壳-ID)、服务模块标识符(SPU-ID)和段标识符(段-ID)，在此段标识符是SET数据类型的一种SET值。

一种数据结构“段级”，通过该结构可以在启动段所属的启动层次内定义层次级。该数据结构的类型同样是一种SET数据类型。该数据结构的值，即层次级，被用於检查，在同步点信息内未曾做过试验，越过多於一种层次级转交启动信息。

一种用于定义启动状态和由此定义系统状态的数据结构“同步点”。该数据结构被细分成数据结构“SP-名称”，“条件(Condition)”，“基值(Contributions)”，“SP的定时(Timing of_SP)”，“外部的SP(External SP)”和“动作”。

数据结构“SP-名称”用於识别SP并且是“SET”类型的。

通过数据结构“条件(Conditions)”，可以定义在达到一种同步点之前必须满足的前提(条件)。所述的条件通过涉及过程或其它同步点的关系来表达。

上述条件只允许用来以层次级上升的方向建立关系(例如在层次级4中的一种SP可以涉及到层次级3中的一种同步点)。

经过数据结构“基值(Contributions)”可以定义基值(量值)，它们在实现SP后被提供给至少为一种的其它SP。基值是“动作”的组成部分。

用另外的方式来表达，这些“量值”对於一种“较高级的”SP表示的是条件，这些条件在较高级的SP能够实现之前，必须通过较低级的同步点来建立或满足。

基值只有在增值方向是允许的(这意味着在层次级3中的同步点只准涉及层次级2中的同步点)。

介於SP之间的关系总是包含两种已提到的组成部分，即前提与动作。总是从同步伙伴之一出发进行关系的定义，这意味着在前面所述的实例中要么在SP_x上说明SP_x想对SP_y提供一种量值，要么在SP_y上说明SP_y等候着SP_x的一种量值。这意味着在给一种同步关系下定义时它还是不完整的，总是还缺少一半的关系。这一半在APS产生时通过键接程序/脱机编码程序来补充。

通过介於SP之间的关系，定义启动时的SP的顺序。在此一种SP所在段层次的级是完全不重要的。仅为构造SP(和启动段)才需要层次级，这意味着为了人们不致失去对SP和它们的概观。

通过对另一种SP提供一种SP的基值，如同通过其它SP的“条件(Condition)”那样因此实现完全相同的结果。因此，在给同步关系下定义时，人们有一种自由度。人们利用该自由度以达到“特征独立性(feature independence)”：同步关系总是由在段层次中处在下方很远的SP所定义的。在前述实例中定义会看来像如下那样(前提是SP_x位於较高的层次级上)：

SP_y标明一种“条件Condition)”(等候wait_for)，这意味着SP_y标明，SP_x必须是在它之前被实现的。

通过两种从它们的作用看是等同的语言工具“基值”和“条件”以及通过利用该自由度，启动才可以变为“特征独立的(featureindependent)”。

数据结构“SP的定时(Timing of_SP)”包含，显示允许一种段的最大持续时间的信息，以便从一个同步点向前跨进到下一个同步点。如果在通过该最长持续时间确定的定时器走完之前，同步点未被达到，通过一种相应的标记对相应的错误发出信号。

数据结构“外部同步点”表明，显示该同步点的局部先决条件已满足的消息是否应送往所谓的母平台(parent platform)。该母平台是那种承担对从属子平台的维护活动作检查的平台。因此该数据结构用於跨平台的同步和由此同样地表示着一种与同步点有关系的应实施的动作。

同步消息只应送往母平台而不送往所有邻近的平台(它们对於各单个子平台是完全不知道的，只能从数据库中读出，而该数据库在启动过程中才被装入的)。

在迄今於启动段中被说明的启动信息已被表示之后，现在则说明那些对参与同步启动的用户过程是重要的启动信息。

用於一种过程的启动信息的说明，在此只能涉及那些在该过程所属SPU内被定义的同步点，这意味着在这种SPU内该过程是已被说明的。

所述用於一种过程的说明能脱机地，这意味着由编译程序和/或由联编程序处理，以便由此产生包含在启动表格中的信息。

下述说明或由此生成的启动信息是可能的：

对於一种过程可以通过说明“Start_at_SP”确定，何时，这意味着在实现何种SP时，应启动一种过程。该说明在一种所谓的启动表中引起一种项，该表是对每种同步点存在着的，并对在该SP上应启动的一些过程编目。在包含应启动过程的模块内进行说明。

此外一个过程有可能性来表明，它希望被暂停，直到实现一种一定的同步点为止。该可能性通过操作系统调用“Wait-for-SP”的说明来实现，在此操作系统调用(管理调用(Supervisdry Call)简写ASVC)作为传输参数必须包含的一定SP的数据。

除此以外，一种过程可以要求，当一定的同步点(在它的SPU之内)已被达到时可得到通知。这是在两个部分内实现的。

通过一种说明来实现第一部分(静态部分)，根据此说明脱机地向每种SP都存在着的一种“监视表(Watch-Tabelle)”中进行输入，该监视表收录过程的监视要求。在包含着应启动过程的那种模块内进行此说明。

第二部分(动态部分)通过操作系统调入“监视SP(Wait_for_SP)”，在正要求着的过程本身中来实现。

最后，一种过程-在其启动之后-可以向一种同步点提供一种量值和通过操作系统调用“提供给SP(Contribute_to_SP)”的说明在它已进行的量值之后向一种SP表明，该量值是已被满足的。这又以两个部分来实现。

通过一种说明来实现第一部分(静态部分)，根据此说明脱机地向每种SP都存在着的一种“基值表(Kontributions-Tabelle)”中进行输入，该基值表收录过程的基值显示。在包含着那种应启动过程的模块内进行此说明。

第二部分(动态部分)通过操作系统调用“提供给SP(Contribute_to_SP)”在正显示着的过程本身中来实现。

在“提供给(Contrib To)”的情况下这两部分在逻辑上是需要的：-用通告表(Table Announcement)(静态部分，说明)促使所属的SP等候过程的基值。-该过程(在它已执行必要的动作之后)用操作系统调用“提供给SP(Contribute_to_SP)”进行它的对SP的量值，这意味着该过程以该操作系统调用告知启动(Sstart-Up)，它用於SP的前提已得到满足。-与之相对地“等候(Watch For)”的两个部分，在逻辑上是不必要的；只有当人们用之可以发送消息的缓冲标识符(Buffer-ID)是脱机地未知的时候它才是必要的。在这种在此假设的情况下它们必须联机地被告知启动(Start-Up)；静态部分为此仅保留启动(Start-Up)所需要的位置，以使该(脱机未知的)缓冲标识符可以被输入。

以下详细说明启动控制程序SUPO_SYNC和SUPO_PROCESS的功能。

启动控制程序利用启动表格，(如同已提及的那样)，以便控制启动。确切地说，它们控制同步了的启动，其方法在於，它们将SP-单元从一种状态引导到另一种状态。

各SP的处理不受层次级和它们所处外壳的影向。

由於与各SP联系着的任务的原因，有必要在SUPO_SYNC和SUPO_PROCESS之间进行区分；在此对於所有的SP的相同的任务总是由相同SUPO-部分来实施。

SP的处理几乎完全通过SUPO_SYNC。SUPO_SYNC来检验前提是否已满足，并且必要时执行动作(包括将新“准备好的”SP-单元挂入“就绪存储池”)。

SUPO_PROCESS只承担在APS的外壳3中不能执行的任务：-SP的时间监视-在外界SP的情况下通往母平台的通信-推动启动表格的初始化和启动同步机制。

图3说明一种SP-单元能够呈现的三种状态和将SP-单元从一种状态引导到下一种状态的方式和方法。

整个启动方法被初始化，其方法在於，使第一种SP-单元准备好实施，这意味着被引导到“就绪”(“ready”)状态。这可以例如经过一种专用接口来进行。

根据介於SP之间的关系，必须仅一次地使“第一种”SP“就绪(ready)”，这意味着不必(而且也不准)在每种SPU中使第一种SP“就绪(ready)”。而是根据这些由“第一种SP”到另一些SP的关系它们自动变为“就绪(ready)”，因为“第一种SP”的动作包含着对其它SP的基值，和其它一些SP根据这些基值可以变成“就绪(ready)”。在所附的图(图4)中，该“第一种SP”是“SPU5”中的第一种SP。

图4表示一种在考虑过程级的情况下的典型的启动。

每当一种过程作一种基值，SUPO_SYNS就检查所属SP(过程对其作了它的基值)的全部前提是否已得到满足(这意味着机理是事件控制的)。

如果一种SP的全部前提是满足的，则(由SUPO_SYNC，还在提供给SVC(Contribute_TO_SVC)的范围内)执行SP的动作：-有时一些过程被启动，-向过程发送消息，-重新唤起被推迟的过程和-作出对其它SP的基值。

根据这些动作，在提供给SVC(Contribute_TO_SVC)的范围内，其它的SP还可以变成“就绪(ready)”(如果对於那些已为之作了提供的SP来说在提供之后全部前提是满足的)。这些SP的动作同样地还在提供给SVC(Contribute_TO_SVC)的范围内被执行(等等)。

在全部已“就绪(ready)”的SP的动作已实施后，此提供给SVC(Contribute_TO_SVC)就结束；一种开始运行的过程被选出(由操作系统)。

如同已说明的那样，每种SP包含在该SP“就绪(ready)”之前哪些前提必须是满足的信息。前提可以包含两种组成部分：-事先必须被实现的SP：

此信息要么是直接在该SP上被标明的(如果它等候位於较高层次级中的一种SP的话)要么由连接程序/脱机编码程序生成(如果一个较低层次级的一种SP认为事先必须是被满足的话)。-过程的量值：

在启动过程中过程进行本来的工作。因此它们的量值特别重要。

如同在16)中说明的那样，过程的基值包含两个组成部分：一个静态的和一个动态的。该静态组成部分在此仅为此而存在，即所属的SP“知道”，它必须等候一个确定的过程的一个量值。

SP-单元由“未就绪存储池(nicht_bereit_Pool)”转化为“就绪存储池(bereit_Pool)”，也就是作为以下事件a)和b)之一的结果：a)SUPO_SYNC对於处在“未就绪存储池(nicht_bereit_Pool)”里的而在段级上的SP做一量值。在完成该量值后SUPO_SYNC检查是否同步点的全部先决条件都得到满足。如果是肯定的话，则SUPO_SYNC将该SP-单元引导进入“就绪存储池(bereit-Pool)”。b)一个过程完成一项对启动是重要的任务，并且该任务经过已描述的说明(或通告表(table announcement)或过程基值的静态组成部分)作为用於某种确定SP的前提而处在启动表中(Start-Up-Tabelle)。

在完成此任务后，该过程调用语句提供给SVC(Contribute_TO_SVC)，在其范围内进行前述动作。

通过由SUPO_SYNC控制的动作，来实现将一种SP-单元从状态“就绪(bereit)”转化到状态“结束beendet”中去。

与一种同步点相联系，可以实施以下动作：-与同步点相联系，必须由操作系统启动的一列过程，-必须对其它SP-单元做出基值，-在等候长队中，等候着该同步点被达到的一列过程，重新被排入“准备就绪运行(ready to run)”的等候长队中，-当该同步点已被实现时，将一种标准消息送向所有那些想被通知过程的缓冲区。-一种段的若干SP-单元由SUPO推动进入“就绪存储池(ready_Pool)”。(如果下一个同步点的全部先决条件在同一段的范围内是满足的，测该段的下一个同步点准备就绪被实施，并且该同步点因此被推动进入“就绪存储池(ready_Pool)”)。

如果一种同步点的全部所述动作已经实施，则在该SP-单元范围内设置一种相应的标记。

归纳起来可以说，采用将一种SP-单元从就绪存储池取出的办法，SUPO_SYNC促使将此种SP-单元从“就绪”状态转入“结束”状态。SUPO_SYNC将各SP从该存储池取出的次序是无所谓的。在“就绪存储池(ready Pool)”中的全部SP已经实现和所有这些SP的动作必须被实施。

实际上这些存储池是作为SP-单元的链来实现的。在处理时先从链中前部开始，并且总是链中的下一种被处理；新的SP挂入链的后部。因此保证了所有的SP被处理。

此外实际上不存在“非就绪存储池(not ready Pool)”和“结束的存储池”(“finished Pool”)。这些存储池通过在SP-单元中的标记来代替，这些标记指明，还缺少多少种用於一种SP的前提或一种SP的动作是否已经被处理完毕。

如果在该就绪存储池中不再存在SP-单元，SUPO_SYNC则不再有工作，并且必须等候，一种用户过程借助於操作系统调用“提供给SP(Contribnte to SP)”将一个SP-单元，转入就绪存储池。

如果具有外部意义的一种同步点被实现了，SUPO_SYNC则不马上实施与该同步点相联结的动作，而SUPO_PROCESS促使向母平台发送消息，通过该消息向此母平台指明，已经到达位於发送信息平台上的所述的SP(这意味着从局部角度看)。同时SUPO_SYNC推迟实施与此同步点相连结的动作，直到从母平台经SUPO_PROCESS已经接收到消息“全局地送达SP(SP global erreicht)”为止。

一种个部的同步点可以被看作为包含两个虚拟的同步点，这通过图5说明。

在段a范围内的第一种虚拟同步点，在与所观察的同步点的关联中，包括同步点的全部(局部)的先决条件，和一种单一的动作，即向母平台发送一种消息(“SP局部被实现”)。

第二种虚拟同步点包括单一的先决条件，消息“全局地送到SP”已由母平台收到，此外并包括所观察同步点的全部其余(局部)的动作。

以下详细地说明用户过程针对启动的操作系统调用(管理程序调用(Supervisory Calls)简称SVC)：

所有通过操作系统启动的过程必须说明，何时，这就是说在何种同步点上，它们应被启动。一旦该同步点已被实现，由SUPO_SYNC启动在此同步点应启动的过程。SUPO_SYNC启动一种过程类型的全部具体型式。

通过用户过程进行的操作系统调用“提供给SP(Contribute_to_SP)”拥有一些参数，这些参数一方面指明段和对之应提供一种量值的同步点(在也包含该过程的SPU范围内)，和另一方面指明该量值是正或是负，这意味着是否该量值已能够被实施或是否出现一种差错。

SUPO_SYNC在它调用后利用段名称和给定的同步点，以便在相应的对之应提供一种量值的SP-单元上存取。该SP-单元在此之后获得一种计时标记，以便指明，该量值已经做出和在何时已被做出。如果由一种SP-单元所期待的全部量值已被做出时，该SP-单元则准备就绪被实施，这意味着准备就绪，与该同步点相联结的动作被实施。这表现在於，由SUPO_SYNC将该SP-单元转入就绪存储池。紧接其后，这意味着在同一调用的范围内在SUPO_SYNC的监督下实施所有与该同步点相联结的动作。

操作系统调用“等候SP(Wait_for_SP)”由用户过程执行，以便使本身暂停，直到已达到某种确定的时间点时为止。该操作系统调用拥有给定段和同步点(在自身的SPU范围内)的参数。

操作系统调用的实施又通过SUPO来进行，在此SUPO利用由操作系统授权的例行程序，以便将已被暂停的过程(确切地说过程监督块简称PCB)与一种在操作系统外壳范围内相应的清单相联结。清单位置又与在操作系统调用中给定的同步点相联结。当该同步点已被实现时，则该过程被从清单中取出并转送到状态“准备就绪运行(ready to run)”。如果该同步点已被实现，当操作系统调用被实施时，引发操作系统调用的过程当然不被暂停。

如果操作系统调用“监视SP(Watch_for_SP)”想被告知一种已实现的同步点的话，这种调用将由一种用户过程执行。为了把用户过程的缓冲区标识符通知SUPO，操作系统调用是必要的，因为在APS的生产时刻，此缓冲区标识符还是未知的(一种过程的缓冲区和由此该缓冲区标识符在运行时才被生成)。

该操作系统调用拥有以下参数：-段和同步点(在本身的SPU范围内)，将把此同步点通知用户过程，-用户过程的缓冲区标识符，-一种应答参数，它向用户过程指明同步点是否已被找到，和清单的缓冲区标识符能否加接缓冲区标识符，后者当同步点已被实现时接收报告。如果应答是否定的，指明同步点已被实现的消息不被送往用户过程。

以下详细说明用於启动脱机支缓的工具：

启动表的生成要求以下的手段：-说明手段(定义手段)，启动段和在其中应接收的启动信息，通过这种手段以合适的方式能够被说明，以及-表格生成手段，它们借助於通过定义手段说明的启动信息生成对SUPO合适的启动表。

所述的定义手段已得到详细说明，现在详细地深入讨论表格生成手段。

为了从为一种处理器确定的服务模块中生成启动表，编译程序首先从在服务模块中包含的段中生成若干部分启动表(段表)。为此目的一种专门的SUP-模块的和用户模块的编译顺序是必要的。此外编译程序将一种服务模块的段表与SPU-逻辑程序设计语言(SPU-Prolog)相联结。

通过连接程序和脱机编码程序建立介於不同段之间的关系。在此对段表加进对此所必要的信息。

根据所述的表格生成手段，在最后的APS-装入生成之前，启动表已可提供使用。因此已经在此时间点上，可以通过相应的检查工具，检查启动的整个过程。该检查手段可以例如从相容性(死锁等等)方面检查启动表，针对全过程范围内的关键性路径进行分析和识别瓶颈和关键的时间路径。(整个)启动表可以由此及早被优化。

最后该(整个)启动表可以借助於一种显示手段，以相应的启动计划表的形式，被做成对开发者来说是可见的。开发者能够通过此较容易地发现差错。

Claims (8)

1.一种计算机系统的启动系统，具有至少一种确定程序系统的启动(APS)的启动表，和具有借助於在启动表中包含的启动信息，控制启动的启动控制程序(SUPO_SYNC，SUPO_PROCESS)，

其特征在於，

启动表脱机地从启动信息中生成，启动信息是在设计它们的时候在程序系统的软件成分(SPU)中生成的

2.按权利要求1的启动系统，

其特征在於，

启动表是一种由多个部分启动表组成的表格，在此一个部分表每次是通过编译一种软件成分(SPU)的针对启动的说明而生成的。

3.按权利要求1至2中之一的启动系统，

其特征在於，

不同的部分表由用於产生程序系统的生产工具汇合成一种完整的表格。

4.按权利要求1至3中之一的启动系统，

其特征在於，

在一种表格的范围内已经确定，是否应该为了满足一项条件而越出处理器界限之外执行一种同步。

5.按权利要求1至4中之一的启动系统，

其特征在於，

用户软件自己也可以借助於表格定义其启动。

6.按权利要求1至5中之一的实时系统的启动系统，

其特征在於，

表格确定启动，采用的方法是，它们一方面用规定的顺序确定系统状态(SP)，和另一方面确定在实现一种当时的系统状态后应该执行的动作。

7.按权利要求1至6中之一的实时系统的启动系统，

其特征在於，

表格确定系统状态，采用的方法是，它们确定条件(条件(Condition))提供(Contribution))，在它们得到满足的情况下，则认为已达到一种系统状态

8.用於确定计算机系统启动的方法，

按照该方法-在计算机系统成分存储池的一种软件成分中，在其设计的时候，用於将该软件元件并入计算机系统的整个启动的若干启动关系被说明，-从那些为一个用户专用的实时系统的程序系统而从成分存储池选出的软件成分，脱机地生成一种启动表，它确定实时系统的整个启动，并由启动控制程序联机地利用来控制启动。

Images