CN1954293A

CN1954293A - 计算装置中的进程间通信

Info

Publication number: CN1954293A
Application number: CN200580015886.6A
Authority: CN
Inventors: 安德鲁·特尔克
Original assignee: Symbian Software Ltd
Current assignee: Nokia Technologies Oy
Priority date: 2004-04-02
Filing date: 2005-04-01
Publication date: 2007-04-25
Anticipated expiration: 2025-04-01
Also published as: GB2412762A; WO2005096148A2; CN1954293B; WO2005096148A3; JP4782771B2; EP1735707A2; US20070266392A1; US8032895B2; JP2007531138A; GB0407545D0; GB2412762B

Abstract

一种用于计算装置的操作系统，包括具有发布和订阅机制的内核部分，用于提取第一进程发布的属性，以及将提取的属性通知其他一个或多个请求订阅该属性的进程。通过在操作系统内核中设置该发布和订阅机制，可以实时地将属性的改变通知订阅者，而不需要专用的客户服务器机制。可以对该发布和订阅机制设置访问控制属性，其中，该访问控制属性是在确定属性时创建的。还可以将该机制用于计算装置中的消息和消息队列装置。

Description

计算装置中的进程间通信

本发明涉及用于管理计算装置中进程间通信(inter processcommunication，缩写为IPC)的方法，具体来说，涉及改进的发布(publish)和订阅(subscribe)机制，由此可以在属性或事件的发布者和一个或多个请求通知该属性或事件的订阅者之间共享该属性或事件。本发明还涉及用于管理这种进程间通信的计算装置，还涉及计算机软件，具体来说，涉及用于计算装置的使计算装置管理这样的通信的操作系统。

本文中所使用的术语计算装置应广义理解为覆盖任何形式的电器，其包括：数据记录装置(诸如各种形式的数码相机和摄像机)、任何类型或形式的计算机(包括手持和个人计算机)、以及任何形式的通信装置(包括移动电话、智能电话、集通信、图像记录和/或重放、以及计算功能于一体的通信装置、以及其他形式的无线和有线信息装置)。

大部分计算装置都被编程，以在操作系统(Operating System，缩写为OS)的控制下工作。操作系统通过向计算装置的中央处理单元馈送一系列代码形式的指令来控制计算装置。这些指令可以看作是由操作系统调度的一系列准独立基本执行单元。这些基本执行单元分别是所谓的线程以及将在计算装置中执行的、总是包括一个或多个线程的进程。一般的操作系统将调度很多不同的线程，以控制将要通过计算装置执行的各种任务。

操作系统可以看作是由多个部件构成，并且这些部件中的一些部件与其他部件相比，对硬件资源具有优先访问权。具有更高优先访问权的部件被称为优先部件。一个或多个这些优先部件构成通常所称的操作系统的内核。

操作系统的内核以使通常所谓的用户模式程序仅可以通过内核的应用程序接口(API)访问系统资源这种方式，来运行这些程序。用户模式程序通常具有用户接口，这样这些程序一般被称作应用程序。运行在计算装置上的每个应用程序以其自己在装置存储器中的虚拟地址空间来在进程中运行，一个应用程序和另一个应用程序之间的边界被称为进程边界。因此，进程边界确保一个应用程序不会意外地重写另一个进程的数据，这是因为它们的存储器地址空间是完全分开维护的。因此，可以将进程看作是操作系统中的基本保护单元。

然而，存在需要穿过进程边界实现通信的情况，这些通信称为进程间通信(IPC)。对于进程间通信，内核必须提供能够以安全方式穿过基本保护单元(即，进程边界)的机制，从而可以提供这些通信。多数操作系统提供优先(underline)与系统服务器的通信的一个或多个客户/服务器机制。

在某些形式的计算装置(诸如智能电话)中，存在许多可以在操作系统的一个进程中发生并且还可影响操作系统的其他线程/进程的事件。这些事件的典型实例有：

●电话信号强度

●蓝牙连接/断开

●短消息业务(SMS)到达

●输入红外(IR)传输

●电池电量

然而对于这些事件的每一个，都通常有一个主要负责处理该事件的进程，经常在其他进程中存在也影响该事件的其他线程；例如状态显示。

上述类型事件的通知(其需要穿过进程边界)必须标注已经通过使用各种通知服务器在某些操作系统中对其进行寻址的时间。例如，诸如系统代理服务器(System Agent server)和广播服务器(Broadcast server)的通知服务器被包括在可以从Symbian limitedof London，England得到的被称为Symbian OS^TM的智能电话操作系统中。

然而，当存在多个都执行非常相似的任务的上述类型的服务器时，将伴随有每个服务器各自对全部系统资源的要求。并且，可以将这些服务器中的每一个都看作是相对“特别重要的”带有相关的相对较高资源请求的服务器，因此对这些服务器的使用使得对系统资源的整体要求相对较高，并且因此，不希望认为该整体要求在诸如智能电话的计算装置中具有相对受限制的物理资源。

另外，使用上述类型的多个服务器在本质上要求客户/服务器接口之间硬连线的可靠性，进而导致限制了系统结构灵活性。例如，对于某些操作系统来说，不包含专门的通知服务器，就不能在ROM中包含通信能力，即使本来不需要该通知服务器。

另外，智能电话具有多个影响装置的整体性能的全局“系统”状态。这些全局系统状态的实例有：

●电源状态-开、关、充电、MP3模式等

●情景状态-静音、大声、在手提包中等

●网络连接状态-GPRS、3G、GSM、无网络覆盖、在线/离线。

然而在装置上运行的某些应用程序可能受到全局系统状态的状态改变的影响，许多只是受到装置的当前状态的影响，以在要执行操作时决定如何在特定点及时采取动作；例如，发送用于以后发送的SMS消息或队列、播放或不播放声音、对按下键做出反应。其他的状态可能不是全局的，但可能需要容易在操作系统的不同区域被共享，并因此可以被看作全局状态的子集。

还要求操作系统管理装置的一些全局状态或值。某些操作系统已经利用了这样的值，但目前，还没有以特别有效的方法处理上面类型的状态。通常，使用专用实例代码(case code)和随机接口。例如，已知是使用至内核中的电源模式的接口，或是使用至用来记录电话正在以特定模式(诸如MP3)工作的特定服务器的接口。因此，当前系统不能很好地处理全局状态，并且确实存在的这些机制是产品细节(product specific)、点对点传输模式(ad-hoc)，并且导致两倍的代码。

“持久性(persistence)”状态是全局系统值的典型实例。持久性状态可以被看作是具有需要持久的状态信息的部件，且还存在需要持久的全局状态。多个部件具有需要持久的状态信息，且还存在需要持久的全局状态。这些的实例包括默认的文件名、本地设置、用户选择等。对于某些项，足以能够获得和设置这些项的值，而其他项要求在项值改变时通知某些线程。

历史上，需要操作系统内核访问被管理的数据，但是对现在更多的操作系统来说，这种要求不再流行；一般的解决办法是要求内核获知数据内容，现在认为这是更可取的。另外，已经提出使用特定系统文件保存这种状态的较高层系统软件，但是在安全操作系统平台的环境中不再认为其是理想的，而一种可选的解决方案被认为是非常理想的。

运行在计算装置上的一个应用程序还可以利用所谓的“发布和订阅(publish and subscribe)”机制与运行在该装置上的其它应用程序直接通信。利用该所谓的发布和订阅机制，第一应用程序(发布者)创建属性，且第二应用程序(订阅者)可以订阅由第一应用程序创建的该属性。然后，发布者发布新的属性值，并通知特定的订阅者该属性已经改变。订阅者然后可以提取该属性的新值。该所谓的发布和订阅机制来自于分布式系统并作为中间件来实现，其中，在该中间件中，通过在操作系统的内核外用户侧运行的两个应用程序之间的所有通信，一个应用程序发布且另一个应用程序订阅。因而，不必在两个应用程序之间建立具体的客户/服务器关系。然而，通信被限制在这两个应用程序之间。

因此，本发明的一个目的在于提供一种改进形式的能在计算装置中进行进程间通信的发布和订阅机制，尤其是要提供可以以更有效的方式、实时实现具有增强的安全性的发布和订阅装置。

根据本发明的第一个方面，提供了一种操作计算装置的方法，该方法包括以下步骤：设置计算装置的操作系统的内核部分以提取第一进程中发布的属性，以及将被提取的属性通知给一个或多个其他请求订阅该属性的进程。

根据本发明的第二个方面，提供了一种计算装置，被设置以根据第一方面的方法运行。

根据本发明的第三个方面，提供了一种操作系统，该操作系统用于使根据第二方面的计算装置根据第一方面的方法运行。

现在将仅通过实例来说明本发明的实施例。

在本文中被称为“P&S”的本发明的方法，提供存储系统范围的“全局变量(globe variable)”和新的进程间通信(IPC)机制的装置，该机制用于在计算装置的操作系统中的线程之间的对等通信。尽管应该理解本发明还可以使用其他形式的计算装置操作系统产生相同的优点，但这里将通过特别参照Symbian OS^TM操作系统来描述本发明的以下实例。

在本发明下面的实施例中，P&S机制包括三个基本部件：

●属性-属性是单个数据值，即，由整型密钥识别的单个变量

●发布者-更新属性的线程

●订阅者-倾听属性改变的线程

可以对属性执行下面六种基本操作：

●定义：创建属性变量以及定义其类型和访问控制

●删除：从系统中移除属性

●发布：改变属性值

●提取：获取属性的当前值

●订阅：登记关于对属性做改变的通知

●退订：撤销改变通知的登记

在本发明中，P&S被设置为既可以被用户又可以被内核程序使用的内核API，且这样通过相似的API还可以在用户和内核代码之间设置异步通信机制。

正如前面的概述，使用一个或多个专用文件是目前用于状态信息存储的优选解决方案。或是可以使用独立文件来保存每个应用程序的状态信息，或是可以使用全局系统文件存储所有应用程序的状态信息。然而，如果使用独立文件，则文件增生导致两倍的代码，并引起在识别所有必需的文件中难度增加。如果使用全局系统文件，则在实际中非常难于实现全局设置应用程序。所有应用程序的状态信息的全局系统文件的使用已经尤其被认为是装置性能的瓶颈，特别在装置启动时。这是因为，在装置操作的初始期间，文件本身就是被严重争用的资源，该文件还包括设置所有客户的API，其中，API将要求访问以获得文件的读/写锁定，并为文件系统在线程之间共享信息。

已经提出了一些对策来改善使用这种全局系统文件的装置性能。例如，在用于智能电话的Symbian OS^TM操作系统中具有通信能力，将相对大量的死锁防止代码设置在操作系统的通信代码中，以有助于某些功能的操作。然而，包含在通信代码中的死锁程序可以产生细微的代码差异，该代码差异通常不明显直到系统整合和测试会引起发展隐患(development concerns)。此外，随着在装置添加更多的通信协议，整个操作系统变得愈加难以测试。另外，死锁防止代码还导致操作系统中的动态链接库(DLL)数量的增加，每一个动态链接库具有相关的ROM空间，因此需要装置资源。

在需要异步或双向(2-way)消息接发的场合，使用了客户/服务器链接的反向。然而，在被设置来提供这种功能的通知程序架构中，通常需要使所有的通知程序提供者位于专用的DLL中，与实际应用程序分离，其中可以期望该通知程序提供者在逻辑上被包括在该实际应用程序中。这导致操作系统中DLL数量的进一步增加。由于其相对限制了物理资源，所以可以认为关于增加DLL数量的任何需要在智能电话中都是特别不期望有的。此外，由于缺少异步消息接发，因此，在执行期间通知程序也难于与其他的服务器联系，这可能导致死锁。因此，也可以认为上述的每个对策在操作系统中引起其它的隐患。

在计算装置操作系统中使用得最普遍的IPC机制是客户/服务器架构。该机制通常是通过从客户进程传送n位量到服务器进程的异步调用来实现的。然后，可以利用合适的线程Read(读)和线程Write(写)调用在进程的线程之间传送更多的数据。

为使用发送和接收调用，总是需要客户和服务器线程必须已经建立了客户/服务器关系。这可以通过利用合适的“CreateSession(创建会话)”调用来实现。该机制被很好地证明是简单和强壮的，以及适于很多通信需求。然而，对于一些应用程序存在着由这些特殊调用引起的隐患。

与线程间的Cancel(取消)调用一样，CreateSession调用是异步调用。因此，当客户线程发出CreateSession调用时，该线程被暂时阻塞，等待服务器对该调用做出反应。因此，如果有A和B两个线程，它们每一个都依赖于另一个的服务，由于两个线程都等待另一个完成它们各自的请求，所以可能造成死锁。然而以此方式相互依赖的两个服务器的实例实际上相对很少，因此，在三个或多个服务器之间形成环时，死锁更普遍些。由于操作系统中客户和服务器的数量随着附加装置功能而增加，因此应该理解，确保新的依赖性不引入死锁的可能性变得愈加困难；而且测试这些潜在的死锁是非常困难和耗时的过程。

对于临时服务器，通常通过将附加句柄(handle)给CreateSession调用来处理该调用，如果服务器没有运行的话，则句柄启动该服务器。术语句柄对于本领域技术人员来说很容易理解，因此在本发明的上下文中将不再描述。然而，句柄的使用包括：把要运行的可执行的名称嵌入客户应用程序的代码中。这样就形成了灵活的系统结构，这是因为没有代码的改变，所以该系统不可能具有不同的部件服务请求。换句话说，由于通过使用句柄，所以CreateSession调用现在要求具体说明特定服务器的名称，实质上，客户机被硬连线，以使服务器能够服务于其请求。

由于CreateSession调用，当客户机启动对目标服务器的调用时，该目标服务器必须存在。然而，存在这样的情况：信息的客户机发送者不要求来自目标服务器的任何响应，特别地，不需要知道发送至目标服务器的信息是否已经确实被接收。在智能电话形式的计算装置中，某些状态更新例如电池电量和通信活动性是该信息的实例。因此，由于客户/服务器架构，所以即使没有服务器客户机实际上也可以运行，该客户机还是被迫依赖于服务器。该附加的依赖性不必要地增加了操作系统的部件之间的连接，减少了系统灵活性，并更难于将操作系统配置到不同的装置。

因此，可以认为客户/服务器机制远离了理想，即，实体不是客户/服务器的关系而是生产者/消费者的关系的这种相互作用。客户/服务器连接不能互换，但在操作系统中存在可以更好的作为两条互换链接的某些通信路径。如上概述，可以克服该缺陷的一种已知方法是反向复制客户/服务器链接。但是本领域技术人员将会明白，这种带有附带的问题的对策导致代码复杂性的增加。

因此，现有状态和事件解决方案之间的许多隐患都与操作系统中客户/服务器架构的可靠性相关。任何通知或状态服务均需要新服务器，且服务器消耗RAM和ROM的大量资源。而操作系统的多个现有服务器可以是可扩展的，以提供该附加功能，而其他的则不是这样的；或者没有可选的方案。所有的这些都在使操作系统适合于计算装置范围的发展时导致资源的进一步加倍，例如当要求大量来自不同生产商的不同的智能电话在普通操作系统的控制下运行的时候。

当前，还没有提供一种真正启用了线程之间的异步通知的机制，因此，必须使用中间服务器。然而，这些中间服务器进而消耗物理资源，并会进一步增加上面详细说明的隐患。

因此，本发明旨在提供一种新型的在操作系统内核中实现的发布和订阅机制。这种P&S机制具有许多优于所有上述发布和订阅机制的优点，且适合于实时系统，从而状态信息项可以被设置和提取，其中，订阅者可以被实时通知状态已经被改变。这提供了一种非常有效的事件通知机制，并且应该明白，这在计算装置操作系统中导致新的IPC方法。

本发明的P&S机制被认为具有以下显著优点：

●许多订阅者都可以监视属性的改变

●发布者和订阅者之间的循环依赖性不会引起死锁

●没有浪费存储器来存储订阅者不想要的属性值

然而，订阅者可能不查看属性所采用的每一个值，发布者不知道何时和/或是否订阅者已经对所发布的新值做出了反应，且很难提供对事件的响应。

因此，在以下条件成立时，可以利用P&S的显著优点：

●需要在系统各处广播事件

●只有最新的属性值而不是中间值被认为是重要的

●提取值的线程不需要知道该值来自何处

●特定状态或事件需要在系统中的多处都可被访问

因此同样地，如果有以下情况，则P&S被认为是不合适的：

●客户机需要来自服务器的服务

●客户机需要响应其请求

●即使在可能存在“内存不足(out of memory)”时，客户机需要确认请求已经完成，可能有错误。

作为内核的实现的P&S API装置还具有以下附加优点：

●还允许将该机制用于用户和内核代码之间的通信。当前，在一些操作系统中，特定装置驱动器通道或硬件抽象层(HAL)功能是实现该通信的仅有途径。

●可以确保实时任务可以发布属性而不损害他们的实时保证——这对于客户/服务器解决方案是不可能的

●在性能方面更有效率——取消了对服务器进程的上下文转换，这可能导致惊人的性能改进。

●允许用户代码使用某些项的持久权能，而用户代码对于这些项本来无法利用其持久权能的。

在本发明的优选实施中，通过由两个32位的部分组成的64位密钥来识别将被发布的属性。属性的名称空间优选地分为由唯一标识符(UID)识别的“类(category)”。每一类优选地包含由32位“密钥(key)”识别的各自的属性，其中密钥可以只是索引或类的其他枚举分类表(enumeration scheme)，或另一个UID(如果类被设置为可一般扩展的)。

还可以设想可以使用不同类型的属性。例如，任何属性可以是单个的32位整数值或长度为0和512字节之间的字节数组(描述符)。类可以包含整数和字节数组属性的混合。然而，一旦属性类型被设定就不能改变，但字节数组属性可以设置为具有不同长度的新值。为了方便，P&S API优选地具有设定和提取字节数组属性为统一代码文本(Unicode text)的权能，在这种情况中优先(underlying)的实现仅将其看作字节。

因为允许使用P&S机制对某些系统API提供实时保证，所以认为上述关于二进制属性的限制是符合需要的。此外，如果是支持任意大小的属性，这将增加不适当地使用P&S API的可能性，造成以下两种可能后果：

●整个属性集合保存在内核存储器中，因此RAM的使用可能增加不必要性

●在引导时恢复持久属性，使得引导时间会惊人的增加

对于本发明的P&S API，属性已经改变的通知是“属性X已经改变(Property X has changed)”的形式，而不是“属性X已经改变为Y(Property X has changed to Y)”的形式。因此，如有需要，将由订阅者明确地提取新属性值。由于该新属性值没有包括在通知中，因此可以将属性值中的多个改变压缩为单个通知，而不是强制所有订阅者都处理属性所采用的每一个中间值。由于在提取当前值之前可以重投通知请求，所以这有助于避免竞态情况(racecondition)，确保了将不会错过更新。

除非系统资源耗尽，不需要在单个属性上强加订阅者数量的限制。然而，在如果不强加对订阅者数量的限制，就有可能影响实时性能时，优选地施加这样的限制。

关于订阅者的完成顺序，可以限定，或者可选地，可以保持不限定。如果顺序未限定，就不会按照订阅者线程的优先级顺序来实现完成。

为满足实时保证，应该对任何要求锁定资源的内核动作限定时间。否则，其他线程将由于没有时间限定而被阻塞资源，导致错过了最后期限。属性值被自动读和写；即，作为单个的不分割的操作。这确保读取任何属性的线程都不会获得误值，或可能弄混淆的多个同时错误的值。然而，这意味着对于每一个更新或提取操作都必须保持锁定。因此优选地，限定可以被复制的数据的大小，以限制保持锁定所花费的时间。此外，由于在操作系统中存储器分配从来不是实时的，所以将可变大小的属性预分配给存储器空间的预定大小，使得发布每一个新值都不需要相应的存储器分配操作。只有在如果新属性值大于预定存储器分配时，存储器分配才是必要的。如果存储器分配确实是必要的，则对于发布操作的任何实时保证都是无效的。

如果订阅是在发布线程的上下文中完成的，因为没有对所处理的订阅列表的大小的限制，所以可以在任意长的时间内挂起该线程。相反的，可以通过使用可选的内核线程(优先级已知)来完成订阅，使得高优先级线程在限定时间内发布值。可以使用操作系统中的监控器(supervisor)型线程来实现该目的。这种线程存在于大多数操作系统中，主要负责清除活动以及将非时间严格的事件通知提供给用户侧代码。这特别有利于属性新值发布的实时服务，因为其可以从时间要求严格的线程调用：例如，智能电话中的通信协议可使用P&S API来指示已经建立了连接。然而，如上概述，如果存在关于任何给定属性的任意大数量的订阅，则本质上，执行时间变为无限定的且实时保证变为无效。可以利用延迟函数调用(DFC)、在监控程序线程上排队，来实施订阅的实际执行，从而解决该缺陷，对于本领域的技术人员来说，延迟函数调用的使用是很熟悉的，因此在本发明的上下文中将不再进一步讨论。属性值由发布者更新且将属性放置在未完成通知的属性的队列上。然后在监控器上下文中由DFC将队列排出(drain)，以及通知订阅者。

可以对每个属性类设置在生成时间确定的安全策略。该策略优选地允许分别地检查对该类中属性的读和写访问。读访问包括提取和订阅属性。每个操作可以具有通过权能或通过安全标识符(SID)控制的访问。优选地，应该将属性设置为只可以由创建它们的应用程序将其从操作系统中删除。该特性也可以由SID控制。

发布和订阅要求在发布者和订阅者之间只有类和属性定义是共享的。然而，发布者可以甚至不存在于保存订阅者的计算装置上，但订阅者仍应正确操作，此外，在这些情况下，确保恶意代码不能够伪装成发布者是非常重要的。因此，即使在订阅者试图提取特定属性而遇到从未发布该特定属性的响应时，任何发布者都应该正确操作，且对不存在的属性的订阅是合法的，以及在第一次发布属性时如愿完成。

关于恶意代码的问题，属性不能够被发布直到创建或限定了这些属性。因此，通过在定义属性时设置属性的访问控制，并确保访问控制不能随着属性而改变，可以为系统定义的类(例如，基于位置的数据)解决该问题。然而，为进一步确保授权的代码只可以发布一个属性，还可以采用以下两种安全装置：

●在非授权的代码运行之前，在引导操作系统期间定义属性，这对发布该属性确保了限定适当严格的策略

●将属性设置在保留的类中，其中，只允许通过具有写入系统数据权能的进程对该类中的属性进行限定

到目前为止所描述的P&S API不包括持久性——所有的属性都是瞬时值。然而，可以通过在属性中增加“持久性”属性来扩展P&S API，以提供属性值的持久性。操作系统中的受信任线程可以来负责提取改变的属性并将它们保存在例如文件中，且还用于在引导期间恢复所保存的属性。这样的装置为系统部件提供安全、实时、全局状态。为了防止持久性特征的无限制的滥用，优选地将属性的存储只限于那些相关的系统软件。

以上述方法提供的持久性没有提供同步持久性；即确保在继续执行之前新的属性值已经写入存储器中。如果需要该特征，可以通过确保对任何属性的改变在发布之后不久保存到持久性存储器中来提供该特征。这提供了一种保存属性改变的有效解决方案。然而，由于将数据保存的重要性，非常优选地，要确保所使用的存储算法通过更新属性具有足够的强壮性预防中途出现失败。

作为操作系统正常关机的一部分，设置P&S API来将未完成的改变提交至存储器，以确保属性的改变不丢失。但是，在突然以及不希望的电源掉电的情况下，不是总能确保任何属性中的所有改变都已经保存。然而，并不认为这是问题，因为在操作系统中，这种“活(live)”属性与其他在电源掉电的情况下操作系统中活的、没有提交的数据没有不同。

还可以将消息队列构造(facility)设置为P&S API的部件。这被认为尤其适合于许多对等通信的当前趋势。通过该构造的设置，P&S机制可以使发布者发送消息到多个订阅关系方，而发布者不需要知道是否任意订阅关系方正在收听；也不需要发布者实际知道任何订阅接受者的身份。

P&S机制的该特征的基本部件是消息和消息队列。消息可以看作是放置在队列上用于传送给接收者的部件。每个消息队列限定了其管理的消息的大小，且该大小通常由操作系统来限定。单个队列可以在许多消息阅读取器(订阅者)和消息写入器(发布者)之间共享。消息具有相关的优先级；较高优先级的消息通常在较低优先级的消息之前被发送——在队列中有效的越位较低的优先级。在本发明的P&S机制中，可以将消息队列设置为可以附带句柄的标准内核对象。以此方式，消息队列“对象(object)”可以在队列中被消息的读出器和写入器打开。

消息和消息对列都不是持久的，这是由于它们在关闭了队列的最后一个句柄之后不再继续存在。因此，可以认为该构造与某些现有操作系统中实现的信箱或消息传送机制相似。因此，根据本发明提供的P&S API以及将这种消息队列构造结合至特定的操作系统中具有附加的优点，这是由于其有助于将代码由具有信箱和消息传送机制的操作系统移植到该特定操作系统。

有五个基本操作需要通过具有消息队列机制的这种P&S API来支持：

●创建/打开消息队列

●发送消息

●接收消息

●队列中等待空间

●队列中等待数据

下面的调用可以用于读或写消息队列中的消息：

“Write(写)”函数调用可以用于在消息队列中放置带有特定优先级的消息。为此，必须事先就打开了该队列。如果队列是满的，可以返回适当的错误溢出请求，例如KErrOverflow，而不是等待打开该队列。之后，如果要求阻塞该错误溢出请求，则调用者可以使用“Wait For Space(等待空间)”调用。随后，一旦队列空间变为可用的，就将该消息将放置在消息队列中。

“Read(读)”函数调用可用于提取队列上的最高优先级消息。在该调用变为可操作的之前，线程必须已经打开了消息队列。如果队列上没有消息，则返回下溢错误请求，例如KErrUnderflow，而不是等待队列中出现消息。然后如果要求阻塞下溢错误请求，则调用者可以使用“Wait For Data(等待数据)”调用，在此情况下，一旦在消息队列中出现消息就立即将其通知给放置Read调用的一方。可以以先入先出(FIFO)的顺序传送消息队列上的相同优先级的消息。

“Open(打开)”函数调用可以用来将任何消息中的重要性(interest)登记在指定队列上。如果队列不存在，则创建队列，因此该调用可能由于没有存储器请求被返回例如KErrNoMemory而失败。该Open调用必须在使用Read或Write调用之前使用。可以使用名称来标识队列，且该调用还可以指定每个消息的大小以及所要提供空间的消息的数量。

还可以使用“Wait For Space”调用。这种调用是异步请求，在队列中存在规定数量的空间(n个消息位置)可用时，将实现该调用。然而，应该设置在任何一个时刻只有单个线程可以使用该特定特征——如果另一个线程当前正等待空间，则可能引起P&S API恐慌。

还可以使用“Wait For Data”调用。这种调用也是异步请求，在队列中存在规定数量的消息(n个消息位置)可用时将实现该调用。和“Wait For Space”调用一样，任何一个时刻只有单个线程可以使用该特征——如果另一个线程当前正等待数据，则可能引起P&S API恐慌。

“Close(关闭)”调用可以用来关闭消息队列的句柄。如果在使用该调用时，没有打开队列的句柄，则删除该队列和任何未完成的消息。

尽管根据本发明的P&S API可以在操作系统中作为使用现有的IPC机制的用户侧服务器来实现，但可以认为内核实现提供了以下附加的优点：

●确保P&S功能性是与客户/服务器IPC真正的对等，且可以提供用于与另一个进程通信的相似性能

●可以确保实时任务可以使用消息队列而不损害它们的实时保证。这不是用于消息队列的基于当前客户/服务器解决方案的情况。

优选地，限制了最大消息大小。通过限制最大消息大小，可以将进一步简化的锁定机制用于消息队列。此外，特别地，已经发现将消息大小限制在36字节可以快速地执行——消息的内容不需要穿过用户/内核边界手动复制，可以将其传送到寄存器中。消息队列本身的大小可以通过对“Open”的第一次调用来确定，这设置了消息大小和数量。如果随后给消息队列分配另外的空间，这有可能使本来会成功的任何实时保证失败。

可以设置消息优先级，且优先级通常可以设置为位于0到7的范围内。可以认为支持优先级的这个范围不会给装置的RAM资源增加太大的负担，然而，即使对于不使用优先级的队列，还是在消息队列中有序的消息提供了足够数量的优先级等级。

不提供安全支持，除了对标准内核资源提供该可用之外。因此对象可能是不安全的以及全局可存取的、对进程私有、或匿名，但是允许由现有句柄的所有者准许访问。

总之，本发明提供了以适于实时系统的方式在操作系统内核中实现的发布和订阅机制。同样的，该机制还允许将该机制用于用户和内核代码之间的通信，因此对落后的客户/服务器结构的隐患提供了一种解决方案。该机制还可以确保实时任务能够发布属性而不损害它们的实时保证。这不是针对任意客户/服务器解决方案的情况。另外，因为排除了对进程的上下文转换，所以该机制在整个操作系统性能方面更高效。

尽管已经参照实施例具体说明了本发明，但是应该理解，在所附的权利要求书所限定的范围中可以对本发明做改变。

Claims

1.一种操作计算装置的方法，包括以下步骤：

设置所述计算装置的操作系统的内核部分，以提取在第一进程中发布的属性，以及将所提取的属性通知给请求订阅所述属性的一个或多个其他进程。

2.根据权利要求1所述的方法，其中，设置所述操作系统，来以包括属性名称空间的第一部分和包括属性类型的第二部分的形式提供所提取的属性。

3.根据权利要求2所述的方法，其中，所述名称空间包括类部和密钥部。

4.根据权利要求3所述的方法，其中，所述类部包括唯一标识符(UID)。

5.根据权利要求3或4所述的方法，其中，所述密钥部包括UID。

6.根据权利要求3至5中任意一项所述的方法，其中，所述名称空间包括由两个32位部分构成的64位整数。

7.根据权利要求2至6中任意一项所述的方法，其中，所述属性类型包括整数值和/或字节数组描述符。

8.根据权利要求7所述的方法，其中，所述字节数组描述符具有可变长度。

9.根据权利要求7所述的方法，其中，所述整数值包括64。

10.根据权利要求7至9中任意一项所述的方法，其中，所述字节数组描述符由0到512个字节组成。

11.根据权利要求7至10中任意一项所述的方法，其中，所述字节数组描述符被设置为统一代码文本形式。

12.根据权利要求2至11中的任意一项所述的方法，其中，所述属性类型具有在创建所述属性时限定的访问控制策略。

13.根据权利要求12所述的方法，其中，在已经创建所述属性之后，不能改变所述访问控制策略。

14.根据权利要求12或13所述的方法，其中，在所述操作系统引导期间限定所述访问控制策略。

15.根据权利要求12至14中任意一项所述的方法，其中，所述访问控制策略对保留类中的所述属性进行设置，其中，所述保留类只允许由具有写系统数据权能的进程在该类中定义属性。

16.根据前述权利要求中任意一项所述的方法，其中，设置所述内核，以只通知所述一个或多个其他进程所述属性已经改变而没有对所提取的属性指定新值，以使所述属性的所述值中的多个改变作为单个通知予以通知。

17.根据前述权利要求中任意一项所述的方法，其中，所述内核部分对订阅所述属性的其他进程的数量加以限制。

18.根据前述权利要求中任意一项所述的方法，其中，设置所述内核部分，以限定将所述属性通知给所述一个或多个其他线程的顺序。

19.根据前述权利要求中任意一项所述的方法，其中，设置所述内核部分，将所提取的属性写入所述计算装置中的存储器空间，所述存储器空间具有预定的大小，而不是由所提取的属性的大小所确定。

20.根据前述权利要求16所述的方法，其中，设置所述内核部分，以仅当预定大小的所述存储器空间中不能容纳所提取的属性时，为所提取的属性的写入分配另外的存储器空间。

21.根据前述权利要求中任意一项所述的方法，其中，设置所述内核部分，以使用已知优先级的内核线程将所提取的属性通知给所述一个或多个其他进程。

22.根据权利要求21所述的方法，其中，所述已知优先级的线程包括所述操作系统内核的监控器类型线程。

23.根据权利要求22所述的方法，包括以下步骤：使用排列在所述监控器类型线程上的延迟函数调用，将所提取的属性通知给所述一个或多个其他进程。

24.根据前述权利要求中的任意一项所述的方法，其中，对所述属性进行设置，使得只能由创建它的进程将其从所述操作系统中去除。

25.根据权利要求24所述的方法，其中，从所述操作系统去除所述属性是由SID控制。

26.根据前述权利要求中任意一项所述的方法，其中，提取和/或订阅所述属性是由SID控制。

27.根据前述权利要求中任意一项所述的方法，其中，所述属性具有持久性特性。

28.根据权利要求27所述的方法，其中，设置所述内核部分，以将所提取的属性存入持久性存储器中。

29.根据前述权利要求中任意一项所述的方法，其中，设置所述内核部分以在一部分操作系统关闭时，将任何未完成的属性的改变提交给存储器。

30.根据前述权利要求中任意一项所述的方法，其中，所述属性包括用于所述计算装置的消息和消息队列构造。

31.根据权利要求30所述的方法，其中，所述消息队列设置有句柄，所述句柄用于使消息队列对象能够由所述消息队列中的消息的读取器和/或写入器打开。

32.根据权利要求30或31所述的方法，其中，所述内核部分限制消息可以放在所述消息队列中的最大大小。

33.根据权利要求32所述的方法，其中，所述最大消息大小为36字节。

34.根据权利要求30至33中任意一种所述的方法，其中，所述消息队列的大小由打开所述消息队列的第一次调用确定。

35.根据权利要求30至34中任意一项所述的方法，其中，放置在消息队列中的消息具有用于在所述消息队列中排列消息的优先级。

36.根据权利要求35所述的方法，其中，排列在所述消息队列中消息具有7个优先级。

37.根据权利要求35或36所述的方法，其中，消息队列中具有相同优先级的消息基于先入先出从所述消息队列传送。

38.根据权利要求30至37中任意一项所述的方法，其中，包括等待空间构造，用于在一方进行了调用以在消息队列上放置消息而此时该消息队列满时，一旦所述队列上的空间变为可用，就将所述消息放置到所述消息队列上，而不需要来自该方的其他调用。

39.根据权利要求30至38中任意一项所述的方法，其中，设置了等待数据构造，用于在接收到来自一方的提取消息队列上的消息的请求而此时消息队列上不存在消息时，就将所述消息队列上出现的消息通知给该方，而不需要来自该方的其他调用。

40.一种计算装置包括：操作系统，被设置来使所述计算装置根据权利要求1至39中任意一项所限定的方法来操作。

41.一种用于计算装置的操作系统，被设置来使所述计算装置根据权利要求1至39中任意一项所限定的方法来操作。