|
实时系统与其他普通的系统之间的最大的不同之处就是要满 足处理与时间的关系。"在实时计算中，系统的正确性不仅仅 依赖于计算的逻辑结果而且依赖于结果产生的时间"（*1）。 对于实时系统来说最重要的要求就是实时操作系统必须有满足 在一个事先定义好的时间限制中对外部或内部的事件进行响应 和处理的能力。这样，实时系统可以定义为"一个能够在事先指 定或确定的时间内完成系统功能和对外部或内部、同步或异步 时间作出响应的系统"。（*2）此外作为实时操作系统还需要有 效的中断处理能力来处理异步事件和高效的I/O能力来处理有严 格时间限制的数据收发应用。就是1.系统应该有在事先定义的 时间范围内识别和处理离散的事件的能力。2.系统能够处理和存 储控制系统所需要的大量的数据。 由于实时系统在设计时与应用的关系非常强，所以有许多分类的 方法。各种分类的侧重点不同。方法一是分为周期性的和非周期 性的（periodic和aperiodic）。周期性的就是系统通过传感器 或其他设备周期性的探测外部环境的变化，在周期内对探测到的 变化作出反应。比如化工厂中的反应炉的控制。非周期性的就是 外部事件是循环性的发生的但不是有规律的或者是突发事件。 比如一架客机飞入一个空中交通管制的管制范围所产生的事件。 方法二是分为硬实时和软实时（hard real_time和soft real time）。硬实时系统就是系统必须及时的对事件作出反应，绝 对不能发生错过事件处理的deadline的情况。在硬实时系统中 一旦发生了这种情况就意味着巨大的损失和灾难。比如控制核 电站的系统，如果没有对堆芯过热作出及时的处理，后果不堪 想象。而在软实时系统中，当系统在重负载的情况下允许发生 错过deadline的情况而不会造成非常大的危害。比如在通信系 统中允许105个电话中有一个接不通。对于软实时系统基于优 先级调度的调度算法可以满足要求，提供高速的响应和大的系 统吞吐率；而对于硬实时系统则完成timely response是必须的。 这两类系统的区别在于调度算法。另外还可以分 为专用系统和开放系统；以及集中式系统和分布式系统 实时系统的设计问题 由于上述的关于实时系统的应用有关的特点，导致在实时 系统的设计时面临着与原来的通用系统所大大不同的考虑 因素。首先在实时系统中最基本的是系统应该能够提供对 时间正确性进行指定的方法。也就是在实时系统中不管是 用户还是开发人员都需要系统提供一种指定时间尺度的方 法。比如在有的实时系统中指定每隔一段时间就运行一段 程序，或者是提供指定程序必须在某个时间点之前完成的 方法等等。在实时系统中这是最最基本的要求。这时通用 系统中的功能就完全的不适用了。例如UNIX和许多类似的 通用系统中都提供一种延时的手段，但这种方法在实时系 统中就无法达到要求，因为这种延时手段无法保证应用能 够在deadline之前完成计算。 第二是实时操作系统的设计或选用。在现代的实时系统当 中一般都有实时操作系统的存在。因为操作系统使系统的 设计更加的简便，保证系统的质量以及能够提供其他通用 操作系统所提供的服务。这样实时的操作系统就面临着更 高的设计要求。本文主要论述实时操作系统，所以关于实 时操作系统的设计要点请看下文。 第三是实时系统的体系结构设计。实时系统的体系结构必 须满足1.高运算速度，2.高速的中断处理，3.高的I/O吞 吐率，4.合理的处理器和I/O设备的拓扑连接，5.高速可 靠的和有时间约束的通信，6.体系结构支持的出错处理， 7.体系结构支持的调度，8.体系结构支持的操作系统， 9.体系结构支持的实时语言特性。另外由于实时系统很多 应用于一些关键性的场合系统的稳定性和容错也非常重要 。还有实时系统很多在自然的形态上有分布式的特点，所 以还要考虑到实时的分布式应用。 此外实时的通信也是实时系统的一大要求，很显然在分布 式实时系统中实时的通信是最基本的。实时通信必须满足 1.逻辑正确2.要有确定的延迟时间（或通信延时时间的上 限）其中包括建立通信的延迟和消息传递的延时。 以上是系统设计时的要点问题。还有从计算机科学角度出 发实时系统必须解决1.时间特性的指定和确正，这点与实 际系统设计相同。2.实时的调度理论。由于实时系统应用 的特殊性以往通用系统中以大吞吐量为目标的调度算法必 须改进以适应实时应用的需要。主要要求是满足时间的正 确性，然后提供高度动态的，满足在线需求的，适应性的 实时调度。3.实时操作系统的设计和实现。在设计上首要 目标是提供保证实时性的方法，包括一系列的经典问题的 针对实时系统的解决方案。实现上要求操作系统的低开销 ，而且必须保证内核以及其他关键的可重入性。4.实时的 编程语言和设计方法。在编程语言级完成或提供实时应用 所需要的方法。比如象Ada语言，FORTH语言，QNX。5.分布 式的实时数据库。6.系统的容错。7.实时时钟的同步。 8.实时系统中的人工智能。 作为实时系统其特性决定了传统的性能衡量标准对其是不适用 的。对传统的通用系统的要求是大的系统吞吐量，合理的响应 速度，对每个系统用户相对公平的进行计算资源的分配。然而 在实时系统中，以上这些要求都不再适用或者是不再占重要位 置。再实时系统中系统的一切动作都以实时任务为中心。实时 的数据吞吐取代了以吞吐量为目标的标准。对硬实时应用的优 先响应取代了对每个用户的恰当的反应速度。系统的计算资源 和其他外设资源必须优先满足实时应用的要求。针对实时系统 新的要求，必须以实时的进程调度在实时操作系统中是一个关键性的问题。 实时操作系统的实时进程调度的根本要求是保证实时任 务的时间正确性。此外实时操作系统的进程调度算法必 须保证系统是可以事先定义的和易维护的。实时任务的 时间正确性以实时任务是否能够总是满足deadline为标准 。第一部分提到过实时系统的类型可以分为periodic和 aperiodic（周期性和非周期性），实时操作系统的调度 理论就是按照这个分类来考虑的。
§2.2.1实时进程调度算法 在控制系统的应用中，实时任务一般来说是各自独立的， 周期性的；也有一些是由外部事件来触发的。这样我们 可以设计一种最简单的调度方法：静态的周期性调度。 这种调度算法的基本思想是将处理器的时间分为"帧"。 一个帧就是一个系统内部时钟触发时钟中断的基本时间一系列不同的标准来衡量系统的性能。间隔。每个实时任务都在帧中占一段时间。仔细的设计 帧的大小可以保证系统中所有的实时任务都能在deadline 之前完成。而事件触发的实时任务则在每个帧中最后一个 周期性实时任务完成之后到帧结束这段时间内得以运行。 这种算法在系统相对简单，任务数少，又可以事先定义任 务的执行顺序的情况下很有效。还有一个更新的版本。就 是将一个大帧分为若干个级别较低的小帧。这个算法又称 为同步任务执行算法。 另外一种简单的调度算法就是FIFO。也就是将系统中所有的 任务组织成一个队列。先到先服务。在简单的和静态的实时 系统中可以事先安排好任务的执行顺序，预先组成队列。这 里要保证的是处理器执行的速度。当任务计算量一定，而处 理器的执行速度合适时，FIFO算法完全可以满足实时的需要， 而且自然的保证时间正确性。在设计队列和应用时要极力避 免关键任务长时间的阻塞。这种算法无疑是不精确的和适应 性差的。 优先级队列算法。这种算法从FIFO发展而来。给每个任务设定 优先级，然后在FIFO中按照优先级排列。这种算法保证了高优 先级的任务的完成，但是对于低优先级的任务很可能无法满足 时间的正确性。而且对低优先级的任务来说等待的时间是无法 预知的。我们无法知道在什么情况下会发生时间正确性上的错 误。而且必须在设计时仔细的检查任务优先级的设定，要保证 不会因为低优先级的任务无法按时完成而破坏整个系统的完整 性。这个算法也是与特定应用有关的。当环境或情况变化时系 统无法随之变化。 以上的调度算法都是独占的，即任务运行时，不允许别的任务 抢先。完成一个任务后才能完成下一个。下面是多任务的算法。 Rate Monatomic/Pacing算法。此算法是基于静态优先级调度 协议的方法。此算法给系统中每个任务设置一个静态的优先级。 这个优先级的设定是在计算任务的周期性和任务需要满足的 deadline的时间的长短的基础上完成的。周期越短，deadline 越紧迫，优先级越高。按周期或计算要求将任务细分成程序块， 整个任务的执行开销为P/(C/CP)( P是周期，C是计算开销，CP 是块的大小)。这样就将整个任务的执行按紧迫性要求分散在整 个周期内。这种算法允许系统以多任务方式执行。 Deadline Driven算法。Deadline Driven算法提供动态的优先级 。因为此算法根据任务满足deadline的紧迫性来修改任务的优先 级，以保证最紧迫的任务能够及时完成。当系统的负载相对较低 时，这种算法非常有效。但是当系统负载极端沉重时会引起大量 的任务发生时间错误（missing the deadline）。甚至可能导致 CPU时间大量花费在调度上，在这时系统的性能还不如FIFO方法 。根据计算当系统负载超过50%时系统性能急剧下降，所以实际 上没有哪个实时操作系统使用这种方法。 Priority Ceiling算法。这种算法用于抢先式多任务的实时操作 系统。该算法的基本思想是在系统中使用优先级驱动的可抢先的 调度算法。也就是系统首先调度高优先级的任务运行。低优先级 的任务在高优先级的任务运行时不能抢先；CPU由高优先级进程 独占。当中断发生时，正在运行的任务被中断，进入中断处理。 如果中断引起的操作是属于一个较低优先级的任务的，那么为了 保证中断被及时的处理，此低优先级进程暂时继承原来当中断发 生时正在运行的高优先级任务的优先级。当处理完关键区域后， 此低优先级任务恢复原来的优先级并被挂起，然后恢复原来高优 先级任务的运行。这种算法保证了高优先级的任务不会被低优先 级的任务所挂起，即"优先级倒挂"现象的出现。 以上主要讲述了在实时操作系统中应用的调度算法的理论。在实 际上现代实时操作系统中往往将上面提到的调度方式结合起来以 适应各种应用的不同需求。比如操作系统提供基于优先级的抢先 式多任务，也同时允许时间片机制。接下来要讨论一下实时调度 算法的正确性问题。 §2.2.2实时进程调度算法的正确性 实时调度算法的正确性主要是指理论上的调度算法能否保证实时 任务的完成。这里仅仅给出一些结论和简单说明。 1. 当C1/T1+ C2/T2+… Cn-1/Tn-1+ Cn/Tn<=n(21/n-1)=U(n)时 （Ci和Ti分别是任务执行的时间和任务的周期），使用 rate monotonic算法调度的一组相互独立的周期性任务必然能够 完成它们的时间正确性。这个定理给出了最坏情况下的系统表现。 保证了静态实时任务调度的正确性。 2. 对于一个相互独立的实时任务集合来说，如果每个任务当同时 开始运行时能够满足时间正确性的话那么不管它们开始的顺序如 何，它们也总是能够满足时间正确性。换句话说就是如果同时开始 运行时是正确的，那么这些任务的时间正确性与它们开始执行的顺 序无关。这个定理的意义在于允许了动态的实时调度。 §2.3实时系统的内存和外围设备管理 在计算机系统中内存管理主要有两个基本的任务。 第一也是基本的是为系统中运行的许多实时或非 实时任务提供共享的内存。第二是提供虚拟内存 。虚拟内存就是将系统的一部分后备的磁盘空间 作为实际物理内存的扩充。由操作系统管理，对 应用程序完全透明。应用程序所能感觉的只有系 统的物理内存变大了。这对于程序员来说是很方 便的。但是享受虚拟内存的好处的同时也是有代 价的，那就是虚拟内存将一部分最近未用的程序 代码和数据换到硬盘上，当要使用时从硬盘读出 的速度要比内存慢很多。这就引起了问题。应用 不知道什么时候会被换出物理内存，也不知道从 硬盘中换回物理内存所花的时间（也就是这个时 间是不确定的）。这样系统响应的时间就变成不 确定的了。这点在硬实时系统中是致命的。 实际上有很多实时系统是没有硬盘的。它们是嵌 入式实时操作系统。一般来说这样的系统组成规 模都尽可能的小，所以一般没有后备存储器。所 以对于实时操作系统来说内存管理必须高效率和 开销必须是可预见的。一种解决方法是预先分配 内存。就是在系统构造或编译时为每个任务指定 其使用的内存空间。这种方法对于硬实时系统来 说是很合适的。而且嵌入式实时操作系统很多都 是在ROM中运行，仅仅只有需要变化的数据才放在 RAM中。这种系统在组成上无疑是静态的。另一种 方法是系统可以有虚拟内存，但必须给实时任务 提供方法，以便将实时任务"锁"进内存，也就是系 统在管理虚拟内存时，不将"锁"住的内存块换出物 理内存。这样可以提供比较好的响应速度和操作的 可预见性。但是不适合硬实时系统。因为虚拟内存 引起的问题并没有解决。 其实实时操作系统的内核仅仅需要负责为程序分配 内存，动态的分配内存和回收内存。为程序分配内 存指当嵌入式系统从主机上下载程序或带硬盘的系 统从硬盘上获得程序代码时，操作系统内核必须为 程序代码和数据分配内存。这种分配规模比较大， 但是在系统运行时较少发生。一般只有在系统启动 或复位时发生。第二种内存管理要求就是在应用运 行时动态的分配和回收数据。一般的实时应用总是 尽量避免动态的分配内存和释放内存。因为这样一 来增加了系统的不确定性。使系统的稳定性下降。 第二种要求还用于实时任务之间的通信。系统分配 信号量，消息队列等等。第二种要求必须高效率的 实现。必须简单和高效。 实时系统的外围设备管理相对比较简单。因为对于 嵌入式实时系统来说，系统中很少有外设要管理。 即使有也是与某个特定的任务相联系，不需要操作 系统来干预。但是对于实时的事务处理来说外围设 备的管理是不可回避的问题。主要是防止实时任务 的死锁。解决死锁的经典算法是银行家算法。但是 在实际应用中这种方法却因为开销太大而很少用。 现在有很多针对某一类应用的死锁解决方法。但主 要思想还是类似的，就是破坏死锁的循环条件。大 多数系统对于死锁都是采用鸵鸟思想。因此很多商 用实时操作系统中死锁的避免是由应用设计人员完 成的。 §2.4实时系统的通信 在实时操作系统中实时的进程间通信也十分重要。特 别是多处理器的情况，通过系统总线或局域网进行 通信。这里主要讨论在分布式系统中的实时通信。 在实时分布式系统中的通信有着特殊的要求。与普通 的分布式系统不同，也与基于总线的多处理器或单处 理器不同。由于系统中没有可以用来通信的共享内存，进程之间的通信完全依靠网络协议来实现。而现有的 网络协议没有一种是为实时应用设计的。对于实时通 信来说当然是网络速度越快越好了。但光有高速的网 络通道还是不够的。必须有可预见的和有确定开销时 间的网络协议。在分布式系统或网络上实现实时应用 的关键点在于实现可预见的和有确定开销的网络协议。 首先看一下局域网。最常用的ETHERNET从本性上来说 就是一个随机的协议。载波侦听/冲突检测本身是一个随 机的协议。想发送数据的机器可能与网络上的其他机 器发生冲突。一旦发生，就放弃发送，随机等待一段时 间后再次发送。不可能给出最坏情况的上下限，这样 就造成了发送数据所需要的时间的不确定性，而这恰 恰是实时操作系统中不允许的。 另外一种局域网的协议是令牌环网。令牌环网的机制 决定了它可以得到发送数据的开销的上限。每个机器 当要发送数据时，首先要得到令牌。得到令牌的机器 可以发送数据。局域网的长度有限，令牌在网上传输 的速度是一定的，令牌环网上所能容纳的字节数也是 确定的，所以可以确定发送一个包最多所需要的时间 。这样的协议是可以被实时操作系统接受的。而且令 牌环网还可以允许带有优先级，允许优先服务高优先 级的任务的通信请求。要实现这一点，只需要在包头 上加上一个代表优先级的字段即可。当发送数据时， 只有优先级高于当前传输的包的机器才能在当前包发 送完后立即发送。这时发送一定大小的包所用的最大 开销就变成仅仅指定为最高优先级的包才能满足这个 上限。 用于局域网中的通信手段还有TDMA（时分多路复用）。 这种机制中每个机器都在网络上有自己的时间片。通信 被组织成固定大小的帧。每个帧含有n个时隙。时隙与 网络上的机器对应。这样就避免了机器发送时的冲突 。每个机器都有确定的带宽。现代的通信技术提供了 高带宽的传输能力，局域网内的实时通信基本成熟。 在广域网上的实时通信也走向应用。通常这种通信是面 向连接的。当建立连接后，实时通信的质量是得到保证 的。通信质量包括最大延迟时间，包发送速度的最大变 化率，最小带宽等等。为了保证通信质量，事先分配好 内存缓冲，表空间，CPU时间，通信信道等。一般用户 要支付占用这些资源的费用，无论他是否使用这些资源。 广域网上的实时通信的最大问题是在广域网上丢包率非 常高。通常解决这个问题的方法是发送者使用一个时钟 ，当超时时，重发数据。但这样会在系统中引起不可遇 见性。发送一个包的开销不可预见这是不允许在实时操 作系统中存在的。一个简单的解决方法是发送者每次都 将一个包发送两次或更多。这样通信的质量得到了保证 ，无非浪费一些带宽而已。 实时操作系统分为嵌入式和普通系统两种。虽然这两种系统 的规模，应用，性能及可靠性要求都不同，但是这两种实时 操作系统都一般是基于微内核的和模块化的。系统可以在最 小规模下工作时，操作系统仅仅提供一些最基本的服务，大 量的在一般系统中由操作系统完成的任务由开发商提供的作 为应用运行的系统级任务完成。所以商业化的实时操作系统 遵循前面提到的开放的系统标准，系统高度模块化。
实时操作系统的内核必须满足一系列特殊的要求。第一实时 操作系统的内核必须非常小。操作系统的内核小，可以为用 户应用留出空间。另外操作系统所占用的内存小也代表了系 统效率的提高。第二操作系统内核必须是可重入的。这一点 对于实时系统来说特别重要。因为不可重入的内核必然带来 慢速的中断响应和不可预料的操作时间。第三系统能够快速 的进行任务切换。快速的任务切换在满足高优先级的任务抢 先时，提供了完成deadline的保证。第四能够快速的响应外 部中断。正如前面所提到的操作系统的内核必须可重入。将 临界区缩到最小可以提供最大的中断响应效率。第五尽量减 少disable掉中断的时间。第六提供固定的或可变的内存管 理机制。内存管理机制在内核中的实现要求尽可能的简单。 高级的功能可以由系统级进程来完成。第七在系统级任务中 提供可高速访问的文件系统。第八系统维护一个满足应用要 求的实时时钟。因为对实时时钟的要求是随应用程序的要求 而变化的。而且实时时钟是与硬件密切相关的，所以一般是 操作系统提供一个接口，真正的管理是要求硬件提供者或用 户自己提供的。第九实时操作系统必须提供一种合适的进程 调度方法。一般商业化的实时操作系统象pSOS和QNX都是提供 的基于优先级的抢先式的进程调度算法。第十实时操作系统 必须通过使用实时时钟的接口来提供time_outs和time alarm 。 第十一实时操作系统还应该提供允许应用任务来自己修改系统 系统中所有进程的优先级的方法和延迟或挂起别的任务的方法。 这样的实时操作系统应该使用高级语言编写，而且不能带有任 何的与硬件有关的特性。操作系统可以向下定义一组接口。由 用户或硬件的提供者来提供实际操纵硬件的程序。包括系统中 设备的初始化和使用。实时时钟也必须这样管理，这样才能保 证不用为每一种嵌入式系统设计不同的内核。这样嵌入式实时操 作系统内核中需要完成的仅仅是内存管理，进程调度和定义一 系列的接口。以及使用接口的基本功能。更高级一些，可以提供 一种进程间通信的方法。这样的实时操作系统内核已经是完善的 了。操作系统内核并没有必要将所有设备都自己管理。况且在设 计内核时谁都想不到会出现什么样的设备。因此在嵌入式系统中 一般是允许应用直接访问底层的硬件设备的。 有一本RTOS的经典是"ucos,the realtime kernerl" ucos支持很多类型CPU，源代码公开，用户非常多，还有人 给它加了个TCP/IP的外壳，是朝鲜的一个家伙，其实是从linux上面改造的 另外，gnu也已经有了自己的源码公开的RTOS叫ecos，可惜现在不支持X86CPU linux现在也有realtime linux，是在linux上内核外面加一个realtime kernerl 把原来的linux kernel 作为最低级别的任务挂上去。 国外有的大学把它用作实时采集系统的应用场合。 我觉得realtime linux是很有前途的，因为linux上面有强大的网络功能 无论linux内核如何升级，都不影响实时模块。 现在又有了mini linux，很小的那种，不知道是否实现了烧在eeprom里面 启动和运行在ram里？ 国外也有了基于linux的机顶盒。 建议大家加入到开发realtime linux的行列来，另外开发一个RTOS就太没必要了 开发一个RTOS内核并不困难，如果不是实现很快的响应速度，很多级别的任务调度 ，支持很多的CPU，还有很多的应用接口和网络功能，否则只有一个内核有什么用呢 就象一辆汽车，你说我们去开发一个发动机有什么困难，但是你知道吗？用户可能 是去抱怨你的汽车上的皮椅怎么那么难坐？！你说我们去开发一个dos有什么困难， 但是开发出来有什么用呢 还是乘上linux这趟快要起飞的企鹅号吧 站在前人的基础上面，增加我们自己的东西，会让自己的成果更有价值！！ 嵌入式的应用开发肯定在未来很有前途，realtime linux也肯定在将来让大家大吃 一惊，pSOS,vxworks等等是很好，但是它们可能象linux那样提供一个又一个的新 的功能吗？而且也还是免费的！要买pSOS的网络OSPF路由包，要XXX万美圆，而且 他们提供的bug修复，不可能又linux那么迅速。。。 讨论半天，其实又回到关于源码公开和不公开的讨论，windows和linux的讨论上 去了:) no no RT Linux 是一个linux的扩展.并不是完完全全按照实时的要求来设计的操作 系统内核.所以它的设计中存在着trade off.我之所以要提出开发自己的RT OS.是 为了借这个计划给有兴趣的同学一个锻炼的机会.而且linux本身结构不适合做RT OS. UNIX中存在的问题,linux中都有.UNIX不是也有实时扩展吗？那要别的系统干什么？ 提到pSOS昂贵的问题。的确是这样所以我们更需要自己开发这样的系统。 至于内核能干什么。这个问题我在计划中已经提过了。首先要有内核，然后再可以 讨论在内核上设计系统级任务，来实现更高级的功能。另外内核上也可以直接设计 应用就向pSOS一样，大量应用是直接在内核上完成的。其实内核的设计只是万里 长征第一步。以后还要做硬件驱动。交叉编译，调试。系统功能的完善比如增加 网络模块等等。还可以扩展到多处理器。我想作为一个学计算机的学生，参与这样 一个计划无疑是对课堂上学到的知识的综合训练。linux是好，不过她的稳定性，安全 性还值得商榷。要不然不都去用linux了？我们自己的内核，我们应该能够对系统做 出修改和保障。linux呢？ 参加RT Linux的开发也是一个好主意。不过各有各的用处。 这些都是我在作论文期间查阅的资料。有兴趣的可以去看看。 1. John A.Stankovic,"Misconceptions About Real_Time computing-A Serious Problem for Next-Generation Systems",IEEE Computer,Vol.21,No.10,October 1988 2. "Real_Time UNIX Systems Design and Application Guide" 3. John A. Stankovic, krithi . Ramamritham,"Advances in Real-Time Systems", IEEE Computer Society Press,1993 4. V.Vande keere,B.Meuris,J.Vandewege,"Embedded Real-Time Intelligence in the Physical Layer of Telecommunication Networks",IEEE Computer Society Press,1993 5. Foundations of Real-Time Computing:scheduling and resource management 6. Software design for real time systems 7. Mechanisms for reliable distributed Real-Time operating system 8. Real-Time system Design Princples for Distributed Embedded Applications 9. Real-Time Systems and Programming Languages 10. Real-Time Systems 11. Lou Salkind,"UNIX for Real-Time Control Problems and Solutions",IEEE Computer ,1988 12. Paul j.Fortier and Michelle Murphy,"Simulation Analysis of Real-Time Task Scheduling",United States Naval Undersea Warfare Center,1994 13. Lui sha and Josh B.Goodenough,"Real-Time Scheduling Theory and Ada",IEEE Computer ,1990 14. Wee K.Ng and Chinya V.Ravishankar,"On-Line Detection and Resolution of communication Deadlocks",IEEE Computer,1994 15. Andrew S.Tanenbaum,"Distributed Operating Systems",Tsinghua University Press,1995
|
|
|
