| OSKit |
作 者： 汤海京
导师：陈朔鹰
前 言
第一章 绪 论
§ 1.1 简介
§ 1.2 安装与配置OSKIT
§ 1.3 使用OSKIT
§ 1.4 OSKIT 导航图
1.4.1 接口
1.4.2 函数库
1.4.3 部件库
1.4.4 执行环境
第二章 线程初始化
§ 2.1 线程初始化分析
2.1.1 线程的创建
2.1.2 线程的存储
2.1.3 线程的数据结构
§ 2.2 PTHREADS/PTHREAD_CREATE.C
2.2.1 创建线程
2.2.2 创建内部线程
2.2.3 为主进程创建一个备份线程
2.2.4 初始化创建线程的线程
2.2.5 为等待和休眠的线程创建一个等待时间
§ 2.3 PTHREADS/PTHREAD_ATTR.C
2.3.1 线程初始化的数据结构
2.3.2 线程属性的撤销
2.3.3 设置线程的警戒堆栈大小
2.3.4 得到警戒堆栈的大小
2.3.5 设置线程的分离状态
2.3.6 得到线程的分离状态
2.3.7 设置线程的继承关系
2.3.8 得到线程的继承状态
2.3.9 设置线程的调度参数
2.3.10 得到线程调度的参数
2.3.11 设置线程调度策略
2.3.12 得到线程调度策略
2.3.13 设置堆栈地址
2.3.14 得到堆栈的地址
2.3.15 设置堆栈的大小
2.3.16 得到堆栈的大小
2.3.17 设置线程的优先级
2.3.18 准备接受调度
2.3.19 声明要进行调度的线程
2.3.20 设置mutex的属性
2.3.21 撤销mutex的属性
2.3.22 设置muxtex的协议
2.3.23 得到线程调度的mutex协议
2.3.24 设置mutex的种类
2.3.25得到mutex的类型
本 章 小 结
第三章 线程通信分析
§ 3.1 线程间通信
3.1.1消息队列
3.1.2信号
§ 3.2 PTHREADS/PTHREAD_IPC.C
3.2.1 消息发送:
3.2.2 send的算法
3.2.3 消息接收
3.2.4 receive的算法
§ 3.3 PTHREADS/PTHREAD_SIGNAL.C
3.3.1 检测并更改阻塞的信号
3.3.2杀线程信号
3.3.3 关线程锁
3.3.4 在目标线程的信号等待队列中加一个信号
3.3.5 信号完成的动作
3.3.6 测试或改变(或两者兼有)主调进程的信号掩码
3.3.7 杀线程
3.3.8 等待信号的线程队列
3.3.9 等待内部信号
3.3.10 线程等待信号
3.3.11 线程等待信号(一般指内部信号)
3.3.12 线程等待信号(有时间限制)
3.3.13 线程等待信号，如果无信号发给它，则无限期等待
3.3.14 从一个陷入发送信号给线程
3.3.15 发出线程阻塞信号
3.3.16 不会被阻塞的信号发送
3.3.17 信号初始化
§ 3.4 PTHREADS/PTHREAD_COND.C
3.4.1条件变量的初始化数据结构
3.4.2撤销条件变量
3.4.3 线程等待条件变量
3.4.4 安全的等待
3.4.5 等待条件变量，但有时间限制
3.4.6 等待捐赠条件
3.4.7 等待条件超时
3.4.8 线程发送信号条件
3.4.9 线程广播条件
本 章 小 结
第四章 线程调度
§ 4.1 线程调度算法分析
4.1.1 线程调度算法的总体描述
4.1.2 优先级逆转法
§ 4.2 PTHREAD/PTHREAD_SCHEDULER.C
4.2.1清空等待调度的线程队列
4.2.2得到等待队列中优先级最高的线程的优先级
4.2.3得到指向下一个要执行线程的指针
4.2.4在线程的执行队列的队尾追加一个线程
4.2.5在线程的执行队列的队头追加一个线程
4.2.6将等待队列中优先级最高的线程提出队列执行
4.2.7从等待队列中删除独占资源的线程
4.2.8此时用到的调度算法
4.2.9将一个线程变为运行态
4.2.10终止该线程目前的调度算法
4.2.11为一个新的线程创建调度参数
4.2.12改变线程的调度状态
4.2.13优先级迁移
4.2.14基于某种原因，线程被送回等待队列
4.2.15返回优先级最高的处于等待状态的线程
4.2.16改变线程的优先级
4.2.17优先级继承
4.2.18不继承优先级
4.2.19优先级递减
本 章 小 结
第五章 OSKIT的应用实例 一个简单系统的设计与实现
5.1设计目的
5.2系统的功能
5.3 我们自己所完成的工作：
5.3.1 系统的启动
5.3.2 线程管理
5.3.3 外设（串口）
5.4 用户手册
5.4.1 安装
5.4.2 用户编程接口
5.4.3 应用程序示例
本 章 小 结
第六章 结束语
后 记
作 者： 汤海京
导师：陈朔鹰
课题名称：基于面向对象操作系统开发平台(OSKit)的分析与程序设计
课题来源：自拟题目
如果说自由软件的出现是一个偶然的话，那么，席卷全球的Linux热潮则是一个奇迹，它正以势不可挡的趋势迅猛发展，其前途不可限量。
Linux内核源代码的开放给希望深入操作系统内部世界的人们提供了可能，但随之而来的问题是，当我们要开发自己的操作系统时，由谁来读系统的kernel部分呢。对这部分的处理从逻辑上分析不外乎三种方式：全部保留、对其进行裁减、全部推倒重来。很显然，最后一种方法是不可能的，而如果我们采用的是第一种方法，其结果当然一定可以满足我们的要求，但是，最后编译出来的核心将十分的庞大，尤其是对嵌入式操作系统的开发者来说，是不能忍受的，所以，大多数开发者采用的第二条路。
但是，第二条路也非平坦的大道，道理很简单，你要想对kernel进行裁减，首先你应该将全部的源代码阅读一遍，并且将其中的相关性理顺，然后才能谈到裁减，所以工作量也十分的庞大。
然而，OSKit的出现改变了这一切，它使得我们不需要将精力集中在kernel源代码的阅读上，因为kernel部分的源程序已经由OSKit的开发人员替你分析过了，他们将源码全部模块化，并将所有模块之间的相关性写在了文档之中，呈现在你的面前，这与你自己分析源代码的结果是一样的。
OSKit最本质的东西和Linux一样，体现在"自由"和"开放"的思想，"自由"意味着世界范围内的知识共享，由于OSKit出现在Linux之后，其设计思想继承了Linux的精髓，所以说它的出现并不完全是美国犹它大学计算机科学系FLUX研究组的功劳，而应该是"自由"的结果。"开放"则意味着OSKit对所有的人都敞开大门，在这种开放而自由的天地里，你可以中分发挥自己的创造才能。
在后面的几章里，我将向大家系统地介绍我的全部研究成果-OSKit的线程机制，希望读者能在最短的时间内了解OSKit，更希望大家能本着"自由"与"开放"的精神加入到我们的研究中来，为中国的自由软件事业贡献自己的一份热情。
我写这篇论文力求达到一个目的，那就是让这篇论文在搞研究的人眼里是一本参考书，而在程序设计者眼中是一本函数手册，既有理论指导，又不是泛泛的空谈理论。
由于本人能力有限，论文中的有些术语表达可能不妥，内容也可能不够准确，敬请各位老师和同学批评指正，本人不胜感激。
汤海京 2000年6月14日
作 者： 汤海京
导师：陈朔鹰
第一章 绪 论
1.1 简介
OSKit是由美国犹它大学计算机科学系FLUX研究组编写的一套模块化部件和库函数，用于架构操作系统内核、服务器以及其他的OS级软件。我们设想一下，在一个操作系统的研发项目中，底层模块的开发工作会占去大部分时间，并耗费掉开发人员的大部分精力。而OSKit的出现恰恰弥补了这个缺陷，其设计意图是提供一套可重用的模块，让使用者避开复杂的底层，把精力集中在他们感兴趣的问题上，也就是说，当开发人员拿到OSKit之后，便立刻拥有了一个完整而且安全的核心，使他们可以集中精力研发操作系统的高层次问题，如作业控制、虚存、IPC、文件系统、系统安全以及高级语言（如Java、Lisp或ML）等。这样可以大大丰富操作系统的应用层，为用户提供更多更好的服务，提高操作系统的运行效率，增强操作系统的安全性和稳定性，从而使你的操作系统更加具有魅力。
对于站在操作系统技术最前沿的多线程编程和成熟的作业控制系统，以及时下最流行的嵌入式操作系统，OSKit都提供了支持。通过几个月以来对美国犹它大学计算机科学系FLUX研究组网站的追踪，我们注意到OSKit的版本大约每三个月就更新一次，我们在毕业设计初期拿到的是99年7月的版本，而我们写演示程序是用的2000年5月的版本，在此期间又出现了99年12月版和2000年2月版，而且在每次发布的版本里都有许多新的算法公布，还有许多老版本中的BUG被修改；这说明OSKit不但一直处于操作系统开发平台的最前沿，而且其自身也在不断的完善。
通过对OSKit深入细致的分析与研究，我们发现犹他大学的开发人员们从一开始就确定了自己的目标，那就是对OSKit进行模块化，仿佛Windows中的动态连接库一样，让后来者即使不使用OSKit中的某一部分，仍然可以使用其余部分来完成他们的目标。这样的设计思路十分灵活，为开发者和使用者都提供了便利。
1.2 安装与配置OSKit
当我们从犹他大学得到OSkit的五月版时，它是个压缩包，使用tar在linux下解开后，就得到了源码，这需要我们在linux下重新编译。
目前，编译OSKit需要以下的工具：
GNU make
GNU CC (gcc) 2.95.2版。
注意：到目前为止，我们使用的Redhat Linux 6.2中的GCC并不是2.95.2，如果要成功编译OSKit，需要先将我们的GCC升级。当然，如果你使用的是Turbo linux 6.0的话，它提供的就是GCC 2.95.2。
在开始编译OSKit之前，我们必须注意一点，那就是要对源码进行一点改动，让它支持实时操作，即将 /oskit20000505/threads/MakeFlage 中的：
# OSKIT_CFLAGS + = -DPTHREAD_SCHED_EDF -DPTHREAD_REALTIME 中的注释符号 # 去掉。
由于我们的环境是Linux，所以论文中的根目录用"/"表示，而不是Windows中的"\"。
由于我们是在intel 586上编译,而我们的目标机要支持到intel 386，所以我们应该在OSKit的目录下键入：
./configure ――host=i586 ――target=i386
此后键入make，编译OSKit。
当OSKit编译好以后，你可以用"make install"命令来安装它。在缺省的情况下，这些库会被安装到/usr/local/lib中，而头文件会被安装到/usr/local/include中，除非你在配置时使用了--prefix选项来指定它。所有的OSKit头文件都安装在oskit/子目录中（例如/usr/local/include/oskit），不会和已经存在的任何头文件冲突。即使是库被安装在主库的目录中（如/usr/local/lib），所有的库文件都有前缀oskit_，这可以避免和其它不相关的库混淆在一起。
1.3 使用OSKit
一开始，为了能让大家尽快熟悉OSKit，犹他大学的研发人员们给出了许多很具代表性的例子供使用者进行试验，而我们的课题组也编写了一个小型的操作系统，供学习研究之用。
OSKit中库的设计是很经典的，开发者们花费了大量时间清楚地标出了每个库与其它库的依赖关系，这使得OSKit不但保留了操作系统的原汁原味，而且还把库之间的相关性降低到了最低限度，使得使用者可以随意增减其中的库函数。实际上，在很多情况下，特别是在某些函数库中，为了有效的使用OSKit，必须替换掉其中的一些函数或符号，以适应我们的执行环境。要重载某个库中的函数或者符号，只要在你的核心或应用程序中再定义一遍就可以了，LINK程序会确保去使用你所定义的函数和符号。由于在Linux下的编译器是靠读取Makefile文件来确定编译连接的对象以及规则，所以我们认为直接修改Makefile文件要比修改OSKit源码更加方便而且安全，这与Windows下的工程文件十分相似。
如果使用OSKit所提供的模块化部件和库函数编写出了自己的操作系统核心代码，并且对在LINUX下用GCC编译源码有所了解的话，就可以借助OSKit为使用者提供的一整套核心制作命令和LINUX提供的GCC来生成自己的核心文件zImage，然后使用LINUX命令DD将核心写入一张1.44MB的软盘，重新启动计算机，从软盘引导就可进入我们自己编写的操作系统了。
另外，考虑到用户环境复杂多样的实际情况，OSKit还提供了对许多种操作系统的支持，包括Linux、Mach 、BSD或者MS-DOS，当我们用GCC将源码编译成"filename.o"的格式之后，使用OSKit提供的不同的核心制作命令来生成不同操作系统下的核心，其具体实现是由mkbsdimage、mklinuximage和mkdosimage来完成的。这些脚本在OSKit的安装和配置阶段会根据你指定的环境自动安装完毕。在每一个脚本运行的时候都有各自不同的参数。
1.4 OSKit 导航图
OSKit所提供的功能被分成三类：接口、函数库和部件库
1.4.1 接口
OSKit的接口非常清晰，并且是面向对象的。这些接口全部被定义在C语言的头文件中，我们分别对其加了必要的注释，以方便使用者快速掌握OSKit。这些接口被OSKit的各个部件共享，从而体现了各部件之间的一致性。操作系统的开发人员既可以直接使用它，也可以在其上定义目标操作系统的接口结构。
1.4.2 函数库
OSKit的函数库以C语言中面向函数的方式提供基本的服务。一个库中的函数对另一个库中函数的依赖关系已经被降至最低的程度，如果这种依赖是不可避免的话，那他们已经被很清楚地标注出来，展现给了操作系统的开发人员。函数库很少使用OSKit的面向对象的COM接口，取而代之的是在C的头文件中定义自己的面向函数的接口。这种设计策略为操作系统开发人员提供了灵活性和极大的技术支持；要适应任何特殊的操作系统环境，底层的OSKit工具必须具有可扩展性。
1.4.3 部件库
OSKit的部件库使使用者能站在更高的层次来编程，即面向对象的"黑盒"方式。尽管OSKit的"部件"在缺省情况下也是被打包成为普通的链接库，但它们的结构则是被设计程面向对象的，而不是传统的面向函数的方式。与OSKit的函数库相比，部件库通常只对外开放一些相关的公用调用接口，而不是大量的功能。例如，在Linux和BSD的驱动程序部件库里，每一个完整的驱动程序仅呈现为一个单独的函数调用，这个调用用来初始化并注册驱动程序。
1.4.4 执行环境
OSKit中的许多部件在核心和用户方式下都可以使用，这就需要对部件的执行环境作出定义，例如部件什么时候可以嵌套进入等。此外，OSKIT使用了许多其它操作系统的代码，例如设备驱动程序和网络协议栈，都是原封不动的从原有的核心如BSD和Linux中借用来的，OSKit通过附加代码模拟原始执行环境使的这些执行模块比它们原始执行环境更简单，用户也不需要详细了解原执行环境的细节。下面对OSKIT的每种执行模块进行简单的介绍。
纯执行模块：这是OSKit执行环境中最简单的一个模块，这些部件或函数中没有全局变量或静态变量，只使用和处理由目标环境传递来的数据。例如函数strlen,它只通过目标环境传递给它的字符串指针求出字符串的长度，并将其返回，它只接触参数数据域，而不影响目标环境。当这些函数使用的数据集是分离的，它们可以安全地同时被调用，而不需要同步，反之则不行。例如对重叠的目标缓冲区并发使用memcpy调用时不安全的。
非纯执行模块：这些模块中使用了全局变量或有可能改变全局共享状态，例如liboskit_kern（核心支持库）中的许多函数建立和访问全局处理器寄存器和数据结构，因此它们是非纯执行模块。非纯执行模块有以下特点：非纯函数和部件可能依赖于全局状态，如全局变量，静态变量，处理器中的特殊寄存器等。除非有明确的声明，非纯函数和部件是不可重入的，并且运用在多线程系统中也是不安全的。为了在一个多线程/多处理器环境中使用这些函数和部件，目标操作系统必须提供适当的同步代码。
阻塞模块：它扩展了非纯模块来支持非抢先的多线程，这些模块中有一类可重入的函数称为阻塞函数，在这模块中，除非明确声明为非阻塞函数，否则函数是阻塞的。为了在一个完全抢先的、可中断的或者多处理器的环境中使用阻塞模块，必须在进入模块前加锁，在退出模块时将锁释放。
可中断阻塞模块：在它之中每个部件都是一个单线程的执行域，在一个给定的时刻，只有一个（虚拟的或者物理的）CPU可以执行部件中的代码。例如：在一个多处理器系统中，在进程级别下，任意时刻在一个部件集内只有一个CPU被允许执行；这能够通过在部件前后放置全局锁来实现。
在一段时间内，部件中可以存在多个活动进程，但在某时刻只有一个进程被执行。目标操作系统给每个活动进程提供一个独立堆栈，这个堆栈在阻塞函数运行时被保留。只有在操作完成后，对部件的调用返回时才放弃该堆栈。部件中的代码总是运行在两个级别中之一，进程级或中断级。有意思的是一些部件的函数和方法只能在进程级别被调用，而另一些只能在中断级别被调用，还有的能在任何级别被调用。调用的细节属于接口描述的一部分。
部件中无论进程级别或中断级别的操作都能被部件中的中断处理程序中断，除非代码调用osenv_intr_disable屏蔽了中断。当部件在进程级运行时，OSKIT假定中断开放，部件在处理过程中可能临时屏蔽掉中断，但必须在返回到目标操作系统前重新激活。同样，当部件在中断级运行时，OSKIT假定中断被屏蔽，但是部件可以在目标操作系统允许其它中断级别的活动中断该部件时重新激活中断。
当目标操作系统在一个部件内中断一个进程级别的活动时，在继续这个活动前，操作系统必须执行完这个中断级别的活动。同理，若一个中断级的活动被中断，那么最近的中断级别的活动必须在继续前一个中断级别的活动之前完成。部件中运行在中断级别的代码不能调用目标操作系统提供的阻塞回调函数；只有非阻塞的回调函数能够在中断级别被调用。
OSKit的线程机制 第二章2000年12月18日22:59
作 者： 汤海京
导师：陈朔鹰
第二章 线程初始化
前面我们曾经谈到，在OSKit中资源分配和调度的单位是线程而不是传统意义上的进程，所以我们有必要花大量的时间对其线程机制做全面的分析。当然，要分析线程部分，首先应该从线程的初始化入手，然后才能涉及到线程间的通信以及线程调度，所以本章将向各位全面系统地介绍OSKit的线程初始化。
为了让大家能清楚地掌握OSKit的线程部分，在以后的三章内，我将采用理论实际相结合的论述方式，即在每章的开始先论述本章所要讨论的线程机制，以期让大家在概念上对本章有总体上的认识，然后再针对OSKit的源代码做进一步的阐述，希望能理论实践双丰收。
2.1 线程初始化分析
2.1.1线程的创建
在OSKit中，用户创建一个新线程的唯一方法就是调用创建线程的线程pthread_create。
内核为系统调用pthread_create完成如下操作：
(1) 为新线程在线程表项中分配一个空槽。
(2) 赋给子线程一个唯一的标识号
(3)制作一个父线程上下文的逻辑副本。由于线程的某些部分，如正文区，可能被几个线程所共享，所以内核只要增加某个区的引用计数即可，而不用真的将该区拷贝到一个新的内存物理区。
(4)增加与该线程相关的文件表和索引节点表的引用数。
(5) 向父线程返回子线程的线程号。
系统对一个用户可以同时运行的线程数有一个限制（这个限制是可以改变的），因而任何用户不能使用过多的线程表项，不然的话，就会妨碍其他用户创建新线程，而且，OSKit为了防止死锁，规定了普通用户不能占用线程表项中的最后一个线程，这条规定是从UNIX中演变而来的。
2.1.2线程的存储
OSKit的线程存储方案与UNIX十分相似，由三个逻辑段组成，它们是正文段、数据段和栈。正文段含有一个线程所执行的指令集合，正文段的地址包括正文地址（用于分支和子程序调用）、数据地址（用于存取全局数据变量）和栈地址（为了存取子程序的数据结构）。
若机器将生成的地址看作物理存储器中的地址，那么，两个线程在它们所生成的地址集合重叠了的情况下，是不可能并发执行的。虽然编译器可以产生在程序之间不重叠的地址，但这样的程序对于通用计算机是行不通的，因为一种机器上的存储容量是有限的，而所有可能被编译的程序集合是无限的。采取此种方法可以在很大程度上避免数据的丢失。
2.1.3线程的数据结构
以下我列出了OSKit中线程的完整的数据结构，其中大部分是从UNIX中继承来的，但也有一些是OSKit自己的，例如，为了制作例子程序所提供的CPU资源分配的部分。
为了使各位一目了然，我对此数据结构做了全部注释，并按照其不同应用领域划分成了几个部分，分别加在了下面的注释之中。
queue_chain_t runq; /* 释放队列链 */
pcb_t *ppcb; /*指向PCB的指针 */
oskit_u32_t pstk; /*指向所分配的堆栈的指针*/
void *(*func)(void *); /* 指向执行函数的指针*/
size_t ssize; /* 所分配的堆栈的大小*/
size_t guardsize; /*警戒堆栈的大小 */
pthread_t tid; /* 线程号 */
oskit_u32_tflags; /* 线程状态标志 */
pthread_lock_t lock; /* 锁*/
queue_chain_t chain; /* 队列链 */
int preempt; /*线程优先级 */
/*以下用于对死锁的处理*/
pthread_mutex_t mutex; /* 互斥位(死锁保护)*/
pthread_cond_t cond; /* 等待死锁标志=1 */
int dead; /*死锁了 */
/*例子所用到的资源*/
int cputime; /* 占用CPU的时间 */
intcpticks; /* 上一秒所占的节拍数 */
oskit_u32_t pctcpu; /* CPU的占用率*/
int childtime; /* 子线程所占用的CPU的开销*/
/*发送信息所用的变量*/
pthread_lock_t waitlock; /* 等待锁*/
oskit_u32_twaitflags; /* 等待标志位 */
pthread_cond_t *waitcond; /* 等待条件变量*/
struct osenv_sleeprec *sleeprec; /*一个osenv_sleep中的线程*/
/*以下是进程通讯要用到的*/
void *msg; /* 指向要发送的消息的指针*/
oskit_size_t msg_size; /* 消息的大小 */
pthread_t tid; /*线程号 */
void *reply; /* 指向响应信息的指针*/
oskit_size_t reply_size; /* 响应内容的大小*/
queue_head_t senders; /* 发送队列中的发送者 */
queue_chain_tsenders_chain; /* 发送队列指针 */
/* 以下是所用到的时钟 */
structoskit_timer *condtimer;
/* 线程的休眠和唤醒是用一个单独的计时器实现的 */
structoskit_timer *sleeptimer;
/* 以下是所用到的信号 */
pthread_lock_t siglock; /*保护锁信号 */
sigset_t sigmask; /* 阻塞信号*/
sigset_t sigpending; /* 未决信号 */
sigset_t sigwaiting; /*等待信号的信号 */
oskit_u32_t eip; /* 页处理故障信号 */
/* 键值通常是一个固定的队列*/
void *keyvalues[PTHREAD_KEYS_MAX]; /* 键值 */
/* 以下用于清除操作*/
pthread_cleanup_t *cleanups; /* 清楚操作链*/
char cancelstate; /* 取消状态 */
char canceltype; /*取消类型 */
/* 以下是单独用于调度的锁*/
pthread_lock_t schedlock;
void *rtai_priv;
intpolicy; /* 调度策略 */
int priority; /* 当前的优先级 */
structscheduler_entry *scheduler; /* 调度程序入口 */
int policy; /* 调度策略*/
int priority; /* 当前优先级 */
int base_priority; /*初始优先级 */
int ticks; /* 调度所省下的节拍*/
oskit_timespec_t start; /* 下次运行的时间*/
oskit_timespec_t deadline; /* 下次运行的时间*/
oskit_timespec_t period; /* 两次执行见的间隔*/
queue_head_t waiters; /* 正在等待的线程 */
queue_chain_twaiters_chain; /* 线程队列链 */
struct pthread_thread *waiting_for; /* 所等待的线程*/
struct pthread_thread *inherits_from; /* 线程从何继承*/
/*以下是CPU的继承*/
struct pthread_thread *scheduler; /* 线程调度程序人口*/
schedmsg_t unblockmsg;
schedmsg_queue_t *msgqueue;
sched_wakecond_t wakeup_cond;/* 唤醒条件 */
schedflags_t schedflags; /* 标志 */
intdonate_rc; /* 从捐赠线程返回的值 */
int timeout; /* 毫秒*/
queue_head_t donors; /* 捐赠资源的线程 */
queue_chain_tdonors_chain; /* 捐赠队列链 */
struct pthread_thread *donating_to; /* 被捐赠的线程*/
struct pthread_thread *inherits_from; /* 线程从何继承 */
structpthread_thread *nextup; /* 下一个要执行的线程 */
2.2 pthreads/pthread_create.c
此源码文件包括了一套完整的线程创建机制，它是全部线程的根源所在，通过阅读下面的函数分析，将使读者了解OSKit到底是用什么函数来具体实现线程创建的。我认为在上一节的理论指导下对代码进行分析，要比泛泛的阐述理论更容易让读者接受，更能加深在读者脑海中的印象。
2.2.1 创建线程
说明：这就是我们在第一节中提到的创建线程的函数，所有由用户完成的创建线程的操作，都要调用它来实现。
intpthread_create ( pthread_t *tid, const pthread_attr_t *attr,
void * (*function )( void * ), void *argument )
tid: 指向线程存储位置的指针
attr:指向线程属性的指针
*(*function)(void *): 当线程初始化时所调用的函数
*argument: 函数功能
2.2.2创建内部线程
说明：该函数用于系统核心部分创建核心线程，而一般的用户没有调用它的权利，只有系统核心才可以调用。
pthread_thread_t*pthread_create_internal ( void * ( *function)( void *), void *argument,constpthread_attr_t *attr)
注：内部线程创建时，将阻塞所有的信号
sigfillset(pthread->sigmask)
2.2.3为主进程创建一个备份线程
说明：出于系统安全的原因，OSKit定义了此函数，用于对主线程进行备份。由于线程创建子线程，子线程又创建自己的子线程，如此下去，将产生一个以主线程为根节点的树形结构，所以一旦主线程丢失，将有可能导致系统崩溃，所以应对其进行备份。
pthread_thread_t*pthread_init_mainthread ( pthread_thread_t *pthread )
2.2.4初始化创建线程的线程
说明：这和UNIX中那个创建进程的进程有些类似，它唯一的工作就是为主线程创建子线程，并且，每个线程都包含一个该线程。
pthread_thread_t*thread_init_mainthread ( pthread_thread_t *pthread )
2.2.5为等待和休眠的线程创建一个等待时间
说明：由于调度的原因，一般线程不可能一直占用CPU，也不可能永远被挂起，所以OSKit为规定线程的等待时间定义了此函数。
voidpthread_prepare_timer ( pthread_thread_t *pthread )
2.3 pthreads/pthread_attr.c
此源码文件包括了一套完整的线程属性的初始化机制，它与上一节的线程创建共同作用，规定了线程在创建之初的属性，通过阅读下面的函数分析，将使读者了解OSKit到底是用什么函数来具体实现线程属性的初始化。
2.3.1线程初始化的数据结构
说明：系统在创建新线程的时候，会调用此函数来规定被创建线程的属性，所以此函数在线程属性机制中站有最主要的地位，是一切线程属性函数调用的源泉，希望读者给以充分的重视。
intpthread_attr_init ( pthread_attr_t *attr )
attr->detachstate =PTHREAD_CREATE_JOINABLE; /* 线程与其他线程关联*/
attr->priority =PRIORITY_NORMAL; /* 线程的优先级 */
attr->stacksize = PTHREAD_STACK_MIN; /*线程所占堆栈的 */
attr->guardsize = DEFAULT_STACKGUARD; /* 警戒堆栈的大小 */
attr->stackaddr = 0; /* 堆栈的大小 */
attr->policy = SCHED_RR; /*线程调度类型 */
attr->inherit = PTHREAD_EXPLICIT_SCHED; /* 线程继承类型 */
注：memset 的数据结构 /* \oskit\libc\string\memset.c */
void *memset(void *tov, intc, size_t len)
{ register char *to = tov;
while (len-- >0)
*to++ = c;
return tov;
}
tov: 指向内存的首地址 c: 分配类型 len:分配长度
2.3.2线程属性的撤销
说明：这个函数是上一个函数的逆操作，在撤销一个线程的同时，其属性也应相应地被撤销，所以OSKit定义了此函数来实现该功能。
intpthread_attr_destroy ( pthread_attr_t *attr )
memset((void *) attr, -1,sizeof(*attr)); /* 撤销指针并释放内存*/
2.3.3设置线程的警戒堆栈大小
说明：警戒堆栈在操作系统中被广泛使用，它是源于UNIX的进程间通信，在UNIX系统中，接受进程的消息缓冲可能小于发送进程。所以，当消息到来的时候，为了避免溢出造成的信息丢失，系统创建了警戒堆栈，用来存储溢出的消息。而OSKit把它用于线程间通信的保护，但用法与UNIX大同小异。
intpthread_attr_setguardsize ( pthread_attr_t *attr, size_t guardsize )
2.3.4得到警戒堆栈的大小
说明：由于OSKit为每个接受线程设置警戒堆栈，所以定义此函数，为的是系统能方便的得到每个接受线程的警戒堆栈的大小，这同样是出于对安全的考虑。
intpthread_attr_getguardsize ( const pthread_attr_t *attr, size_t *guardsize )
2.3.5设置线程的分离状态
说明：上边曾经提到，系统中的线程树，而线程与线程之间很可能并不是完全独立的，即使他们处于不同的层次，也可能有一定的相关性或互斥性，所以定义此函数用来规定线程之间的互斥性，即分离状态是完全有必要的。
intpthread_attr_setdetachstate( pthread_attr_t *attr, int detachstate )
2.3.6得到线程的分离状态
说明：在规定了分离状态之后，若A线程要与B线程发生关联的时候，它必须先看看B线程和其他线程的关系，所以要定义此函数来得到B线程与其他线程的分离状态，提供给A，然后A在根据具体情况决定是否与B发生关系。
intpthread_attr_getdetachstate ( const pthread_attr_t *attr, int *detachstate)
*detachstate = attr->detachstate;
2.3.7设置线程的继承关系
说明：当线程创建子线程的时候，上边我提到的那个创建线程的线程会为他们父子之间规定继承关系，即子线程继承父线程。
intpthread_attr_setinheritsched ( pthread_attr_t *attr, int inheritstate)
attr->inherit = inheritstate;
2.3.8得到线程的继承状态
说明：当系统要在复杂的线程树中得到继承关系的时，调用此函数便能达到预期的目的。OSKit定义此函数，为的是能在复杂的线程树中一眼看穿某两个线程之间的关系。
intpthread_attr_getinheritsched ( const pthread_attr_t *attr, int *inheritstate)
*inheritstate = attr->inherit;
2.3.9设置线程的调度参数
说明：OSKit提供了多种线程调度方式供选择，而且还为每个线程在创建的时候规定了一种调度算法，系统在创建线程的时候调用下面的函数来完成这项工作。
intpthread_attr_setschedparam ( pthread_attr_t *attr,const struct sched_param*param )
int pri = param->priority;
attr->start =param->start; /* 线程开始参数 */
attr->period = param->period; /*线程的周期 */
attr->deadline = param->deadline; /* 线程运行的最终时限 */
2.3.10得到线程调度的参数
说明：在OSKit中，每个线程都有其自身的调度方式，换句话说，就是线程的调度方式仿佛是线程的一个属性，在创建线程的时候就随线程被规定了，所以调度程序可以通过下面的函数来得到某个线程的调度算法和此时它的优先级。
intpthread_attr_getschedparam ( pthread_attr_t *attr, struct sched_param *param)
param->priority = attr->priority;
2.3.11设置线程调度策略
说明：在某些方面，线程的调度策略的确很像线程的属性，但它却是可以在调度中被更改的，系统可以调用此函数完成对线程调度策略的重定义。这样的规定，使得线程调度灵活了许多，当然这种灵活是用增加系统开销的代价换回来的，但却是值得的。
intpthread_attr_setschedpolicy ( pthread_attr_t *attr, int policy )
switch(policy) {
case SCHED_FIFO: /* 先到先处理 */
caseSCHED_RR: /* 时间片轮转 */
case SCHED_EDF /* 先死先处理 */
caseSCHED_RMS: /* 效率优先 */
attr->policy = policy;
break;
case SCHED_DECAY:
printf("pthread_attr_setschedpolicy:"
"SCHED_DECAY not supported yet\n");
}
2.3.12得到线程调度策略
说明：负责调度的线程通过该函数得到被调度线程的调度策略，然后再根据此时系统内的情况，决定是否改变其调度算法。
intpthread_attr_getschedpolicy ( const pthread_attr_t *attr, int *policy)
*policy = attr->policy;
2.3.13设置堆栈地址
说明：调用此函数，可以实现对线程属性堆栈的底层操作，即设置指向该堆栈的指针，并保存起来，为以后的操作奠定基础。
intpthread_attr_setstackaddr ( pthread_attr_t *attr, oskit_u32_t stackaddr)
attr->stackaddr = stackaddr;
2.3.14 得到堆栈的地址
说明：返回指向线程属性堆栈的指针。
intpthread_attr_getstackaddr(const pthread_attr_t *attr, oskit_u32_t*stackaddr)
*stackaddr = attr->stackaddr;
2.3.15设置堆栈的大小
说明：由于系统中的线程功能、大小各不相同，所以其属性堆栈的大小也不尽相同，调用此函数可以设置线程属性堆栈大小。
intpthread_attr_setstacksize ( pthread_attr_t *attr, size_t stacksize)
attr->stacksize = stacksize;
2.3.16 得到堆栈的大小
说明：返回某个线程堆栈的大小。
int pthread_attr_getstacksize (const pthread_attr_t *attr, size_t *stacksize )
*stacksize =attr->stacksize;
2.3.17设置线程的优先级
说明：在操作系统的线程调度中，优先级调度的使用最为广泛，OSKit定义了下面的函数来规定线程的优先级。
intoskit_pthread_attr_setprio ( pthread_attr_t *attr, int pri)
attr->priority = pri;
2.3.18准备接受调度
说明：由于多态性原因，不是所有的线程都要参与调度，只是某些线程参加，所以，系统必须调用此函数，告诉该线程准备参加调度，而被调度的方式在上边的几个函数里已经规定好了。
intpthread_attr_setopaque ( pthread_attr_t *attr, oskit_u32_t opaque)
attr->opaque = opaque;
2.3.19 声明要进行调度的线程
说明：调用此函数是为了告诉系统，哪些线程是要被调度的。
intpthread_attr_setscheduler ( pthread_attr_t *attr, pthread_t tid)
attr->scheduler = tid;
2.3.20设置mutex的属性
说明：在OSKit中，广泛使用了mutex，主要是为了更好的使用临界资源，有效地避免了死锁，换句话说，mutex就像临界资源的数量一样，线程对其进行PV操作。而当一个线程占有了一个mutex，并且在没释放它之前该线程又创建了子线程，此时，子线程理所当然地从父线程手中继承了mutex的所有权，OSKit定义了下面的函数来实现所叙述的功能。
intpthread_mutexattr_init ( pthread_mutexattr_t *attr)
attr->priority_inherit = PTHREAD_PRIO_NONE; /* THREAD_PRIO_NONE=0 */
2.3.21撤销mutex的属性
说明：当占有mutex的线程放弃了它的时候，调用该函数来撤销mutex的属性。
intpthread_mutexattr_destroy ( pthread_mutexattr_t *attr )
memset((void *)attr, -1, sizeof(*attr));
2.3.22设置muxtex的协议
说明：mutex的使用并不是简单的占用与撤销，OSKit还提供了更加完善的mutex协议，它根据inherit的不同，将mutex多样化。
intthread_mutexattr_setprotocol ( pthread_mutexattr_t *attr, int inherit)
switch (inherit) {
case PTHREAD_PRIO_NONE:
casePTHREAD_PRIO_INHERIT:
attr->priority_inherit =inherit;
break;
default:
returnEINVAL;
}
注：在线程调度时，根据mutex协议产生mutex变量，将线程按照优先级排队
2.3.23 得到线程调度的mutex协议
说明：好像对协议的解析一样，调用此函数，可以返回该线程的mutex。
intpthread_mutexattr_getprotocol ( const pthread_mutexattr_t *attr, int*inherit)
*inherit = attr->priority_inherit;
2.3.24设置mutex的种类
说明：mutex在OSKit中是可以多种多样的，通过调用下面的函数，可以规定线程到底占用了哪种mutex。
intpthread_mutexattr_settype ( pthread_mutexattr_t *attr, int type )
switch(type) {
case PTHREAD_MUTEX_NORMAL: /* 普通 */
casePTHREAD_MUTEX_ERRORCHECK: /* 错误检查 */
case PTHREAD_MUTEX_RECURSIVE: /* 递归*/
case PTHREAD_MUTEX_DEFAULT: /* 默认 */
attr->type =type;
break;
default:
return EINVAL;
}
2.3.25得到mutex的类型
说明：当系统想要知道某个线程占用的是什么类型的mutex时，调用此函数来返回mutex的类型。
intpthread_mutexattr_gettype ( const pthread_mutexattr_t *attr, int *type)
*type = attr->type;
本 章 小 结
本章从线程的创建、存储和数据结构到各种属性以及对它们的操作(设置、撤销和得到)入手，系统地阐述了OSKit线程机制的根源--线程初始化。
在第一节主要从三个角度归纳了OSKit中线程所涉及的概念，它们是创建、存储以及线程的数据结构。第二节中以源代码中的/pthreads/pthread_creat.c 为例，说明了第一节中概念的具体实现。第三节以源代码中的 /pthreads/pthread_attr.c为例，说明了Oskit对线程属性的全部操作，包括线程初始化的数据结构、属性的撤销、线程间关系、对mutex的操作以及对属性堆栈的操作等。
OSKit的线程机制 第三章2000年12月25日22:11
作 者： 汤海京
导师：陈朔鹰
第三章 线程通信分析
众所周知，在Linux中，进程为了能在同一项任务上协调工作，彼此之间必须能够进行通信。例如，在一个shell管道中，第一个进程的输出必须传输到第二个进程，这样沿着管道传递下去。因此在需要通信的进程之间，应该使用一种结构较好的通信方式。
Linux支持许多不同形式的进程间通信机制，在特定的情况下，它们各有自己的优缺点，如利用管道进行通信的最大缺点就是，只有成为系统调用pipe的进程的子孙后代的进程才可以使用管道，因此，相互无关的进程不能通过管道通信。
OSKit的开发人员们充分考虑了各种通信方式的利弊，扬长避短，采用了如下的两种线程间通信方式：消息队列和信号量。虽然这还有很多不足之处，但较之SystemV以有所改进。
3.1 线程间通信
3.1.1消息队列
OSKit提供的消息队列机制于UNIX十分相似，一个和多个线程可向消息队列写入消息，而一个或多个线程可从消息队列中读取消息，这种线程间通信的机制就像客户机/服务器一样，客户机向服务器发送请求消息，服务器读取消息并执行相应的请求。
OSKit将消息描述成在内核地址空间的一个内部链表，每一个消息队列由一个IPC标识号唯一的标识。
3.1.2信号
尽管大多数线程间通信是计划好的，但是同时还需要处理不可预知的通信问题。例如，用户使用文本编辑器要求列出一个大文件的全部内容，但随即他认识到该操作并不重要，这是就需要一种方法来中止编辑器的工作，比如说，我们可以按DEL键来实现。按DEL键实际上是向编辑器发送一个信号，编辑器收到此信号便立即停止打印文件的内容。信号还可以用来报告硬件捕获到的特定的中断，如非法指令和浮点运算溢出、超时也通过信号实现的。
在OSKit中，信号是一种重要的线程间通信机制，线程通过信号知道系统中正在出现的事件。信号的一个特点就是它的异步性，这表示线程在它的执行期间的任何时候都可以接受到信号，甚至可能当线程正在执行系统调用的时候接到信号，因此，线程必须随时为相应信号作好准备。
下面我们再谈谈信号的生成与交付，当引起信号的事件首次出现时，就认为信号为线程而生成，也就是说信号被发送到线程。这类事件的例子，包括：时间片到时，终端激活，硬件故障的检测，kill()的调用。在某些情况下，一个事件为多个可以为多个线程生成信号。每个线程采用样应的动作来响应系统定义的每种信号(见信号量表3.1)。
在信号的生成与交付之间，该信号被挂起，但在用户一级是检测不到这个间隔的。每个线程都拥有一个信号掩码(sig_mask)，它规定了当前被阻塞而不能交付给线程的信号集。线程的信号掩码是从父线程继承而来的。我前面提到sigaction(),sigprocmask( )和sigsuspend( )函数，都是对信号掩码的操作。
信号的动作与信号有关的动作分为三种：SIG_DFL,SIG_IGN或指向函数的指针。在最开始，进入main()之前，所有信号都将被置成SIG_DFL或SIG_IGN。
(1)SIG_DFL信号专用的默认动作:
(a)如果默认动作是暂停线程，则该线程的执行被暂时挂起。当线程暂停期间，发送给线程的任何附加信号都不交付，直到该线程开始执行，但是SIGKILL除外。
(b)把挂起信号的信号动作设置成SIG_DFL，且其默认动作是忽略信号(SIGCHLD)。
(2)SIG_IGN忽略信号
(a)该信号的交付对线程没有影响
(b)系统不允许把SIGKILL或SIGTOP信号的动作设置为SIG_DFL
(3)指向函数的指针--捕获信号
(a)信号一经交付，接收线程就在指定地址上执行信号捕获程序。在信号捕获函数返回后，接受线程必须在被中断点恢复执行。
(b)用C语言函数调用的方法进入信号捕捉程序:
void func(signo)
int signo;
func()是指定的信号捕捉函数，signo是正被交付信号的编码
(c)如果SIGFPE,SIGILL或SIGSEGV信号不是由C标准定义的kill()或raise()函数所生成，则从信号SIGFPE,SIGILL,SIGSEGV的信号捕获函数正常返回后线程的行为是未定义的。
(d)系统不允许线程捕获SIGKILL和SIGSTOP信号。
(e)如果线程为SIGCHLD信号建立信号捕获函数，而该线程有未被等待的以终止的子线程时，没有规定是否要生成SIGCHLD信号来指明那个子线程。
每一种信号都被OSKit给予了一个符号名，对于32位的i386平台而言，一个字32位，因而信号有32种。下面的表给出了常用的符号名、描述和它们的信号值。
符号名 信号值描述 是否符合POSIX
SIGHUP 1 在控制终端上检测到挂断或控制线程死亡 是
SIGINT 2 交互注意信号 是
SIGQUIT3 交互中止信号 是
SIGILL 4 检测到非法硬件的指令 是
SIGTRAP5 从陷阱中回朔 否
SIGABRT6 异常终止信号 是
SIGEMT 7 EMT指令 否
SIGFPE 8 不正确的算术操作信号 是
SIGKILL9 终止信号 是
SIGBUS 10 总线错误 否
SIGSEGV 11检测到非法的内存调用 是
SIGSYS 12 系统call的错误参数 否
SIGPIPE 13在无读者的管道上写 是
SIGALRM 14 报时信号 是
SIGTERM 15终止信号 是
SIGURG 16 IO信道紧急信号 否
SIGSTOP 17暂停信号 是
SIGTSTP 18 交互暂停信号 是
SIGCONT 19如果暂停则继续 是
SIGCHLD 20 子线程终止或暂停 是
SIGTTIN 21后台线程组一成员试图从控制终端上读出 是
SIGTTOU 22 后台线程组的成员试图写到控制终端上 是
SIGIO 23允许I/O信号 否
SIGXCPU 24 超出CPU时限 否
SIGXFSZ25 超出文件大小限制 否
SIGVTALRM 26 虚时间警报器 否
SIGPROF27 侧面时间警报器 否
SIGWINCH 28 窗口大小的更改 否
SIGINFO29 消息请求 否
SIGUSR1 30 保留作为用户自定义的信号1 是
SIGUSR2 31 保留作为用户自定义的信号 是
请求按默认的规则进行信号处理
SIG_DFL (void (*)(int))0
请求忽略信号
SIG_IGN (void (*)(int)) 1
注意：信号队列中最多允许有64个信号
3.2 pthreads/pthread_ipc.c
此源码文件包括了一套完整的消息队列型线程通信机制，消息队列是线程通信的主要手段，通过阅读下面的函数分析，将使读者了解OSKit到底是用什么函数来具体实现信号队列，从而进行线程通信的。
3.2.1消息发送:
说明：当一个线程要向另一个线程发送消息的时候，OSKit使用下面定义的函数来实现一个线程向另一个线程传递消息。
oskit_error_toskit_ipc_send ( pthread_t dst,void *msg,
oskit_size_t msg_size,oskit_s32_t timeout)
dst:目标地址 *msg:指向消息的指针
msg_size:消息大小(32位无符号整形) timeout:超时
3.2.2send的算法
发送一个同步消息,直到接收者发送终止消息或超时才结束
为避免死锁,给没个人加一个锁,并关中断。
assert_interrupts_enabled();
disable_interrupts( );
pthread_lock(target->waitlock);
通过条件,检测目标线程是否在等待接受:
条件: a:目标线程的等待标志 THREAD_WS_IPCRECV_WAIT(线程接收等待位)
b:目标线程号存在
c:目标线程等于任意一个线程
d:消息大小不为0
条件成立: a ( b || c) d== 1 才可以发送
if (target->waitflags THREAD_WS_IPCRECV_WAIT
(target->ipc_state.tid ==pthread->tid||target->ipc_state.tid== ANYTID))
{ if(msg_size)
{Memcpy(target->ipc_state.msg,
msg,MIN(msg_size,target->ipc_state.msg_size));
if(msg_size > target->ipc_state.msg_size)
err =OSKIT_ERANGE;
}
}
把数据的大小和发送者的ID告诉接受线程:
target->ipc_state.msg_size= msg_size;
target->ipc_state.tid =pthread->tid;
清除接受位:
target->waitflags =~THREAD_WS_IPCRECV_WAIT;
pthread_unlock ( target->waitlock);
注意: flagA = ~flagB实际上就是将flagB中等于1的位在flagB中清0
发送队列:
queue_enter (target->ipc_state.senders,pthread,pthread_thread_t*,
ipc_state.senders_chain)
target->ipc_state.senders:发送线程的IDpthread:
pthread_thread_t*:指向消息的指针是pthread_thread_t类型
ipc_state.senders_chain:发送队列的指针
队列间参数传递:
pthread->ipc_state.msg= msg; /* 消息 */
pthread->ipc_state.msg_size = msg_size; /* 消息的长度*/
pthread->ipc_state.tid = dst; /* 消息的目的地址 */
pthread->waitflags =THREAD_WS_IPCSEND_WAIT;
/* 消息目的等待位置1 */
3.2.3消息接收
说明：当一个线程要从其消息队列中开始接受消息的时候，OSKit提供了下面的函数供线程调用。
oskit_error_toskit_ipc_recv ( pthread_t src,void *msg,
oskit_size_t msg_size,oskit_size_t *actual,oskit_s32_t timeout )
src: 发送线程的ID *msg: 指向消息的指针
msg_size: 消息大小(32位无符号整形)
actual: 实际消息的大小 timeout: 超时
3.2.4receive的算法
等待从发送线程来的消息
通过条件,检测是否接受消息
a:有等待发送的线程
b:线程等待位THREAD_WS_IPCSEND_WAIT(发送等待标志)
c:发送线程存在
条件成立:a(b||c)
pthread_lock(source->waitlock);
if(source->waitflags THREAD_WS_IPCSEND_WAIT
source->ipc_state.tid == pthread->tid){
*actual = MIN(msg_size, source->ipc_state.msg_size);
if(*actual) {
memcpy(msg, source->ipc_state.msg,*act0ual);
if (source->ipc_state.msg_size >msg_size)
err =OSKIT_ERANGE;
}
}
如果没有等待发送的进程,则让接受进程等待
当发送队列为空且timeout=0时解锁,如果发送了但没接受，则重新初始化发送进程，重新发送。
3.3 pthreads/pthread_signal.c
此源码文件包括了一套完整的信号量型线程通信机制，信号量是线程通信的另一个重要的手段，通过阅读下面的函数分析，将使读者了解OSKit到底是用什么函数来具体实现信号量，从而进行线程通信的。
3.3.1检测并更改阻塞的信号
说明：当一个信号被发送出来的时候，并不一定马上能得到相应，一般来说，它要被阻塞一段时间，但系统也是就不管这些阻塞信号了，系统会定时执行此线程，用以检测阻塞的到底是什么信号，它的含义是什么，然后根据需求作出决定，可以将信号阻塞或者响应。
intpthread_sigmask ( int how, const sigset_t *set, sigset_t *oset )
how:SIG_BLOCK SIG_UNBLOCK SIG_SETMASK
set:如果是空指针，则指向下一个信号
oset:如果是空指针，则指向上一个信号记录
3.3.2杀线程信号
说明：OSKit以及所有的操作系统，都包含这个函数，因为它是操作系统所必须具备的基本功能，也就是说，当一个线程出于无响应状态很长时间，或者因为其他的什么原因线程不能得到执行，则调用它，将该线程杀死。
intpthread_kill(pthread_t tid, int signo)
3.3.3关线程锁
说明：当线程接受到了消息后的响应过程中，有些时候是不希望被其他的线程打断的，所以OSKit提供了此函数调用，用来将线程锁起来，也可以理解为将线程保护了起来。
intpthread_kill_locked ( pthread_thread_t *pthread, int signo )
3.3.4在目标线程的信号等待队列中加一个信号
说明：在信号发送和接受的过程中，线程间通讯并不一定是同步的，此时，OSKit提供了一个消息等待队列，将不能及时得到响应的消息用指针链接成为一个类似与链表的数据结构。当接受线程要响应信号的时候可以直接从消息队列里提取，这样作既可以提高通信效率，有可以增加通信的稳定性。
intsigaddset ( pthread->sigpending, signo )
3.3.5信号完成的动作
说明：在用信号方式通信的时候，线程间传递的信号并不是要做的动作，而是动作的代码，而什么信号对应什么动作，还要有此汉说来进行解析，这样作是为了规范线程间通信，同时还可以节约空间，节省发送和接受的时间，从而大大提高系统的效率。
intsigaction ( int sig, const struct sigaction *act, struct sigaction *oact)
sig：指定信号 act：指向与指定信号向联系的规定信号动作的结构
oact：指向存储先前与该信号相联系的动作的结构
3.3.6测试或改变(或两者兼有)主调进程的信号掩码
说明：所谓掩码就是信号的屏蔽码，比如说，当一个信号被发送的时候，它被自动加载到接收线程的信号掩码中，如果此时又向该线程发送了同样的信号，则阻塞该信号，知道前一个信号响应完毕。
OSKit采用下面的函数完成的对信息掩码的测试和改变。
intsigprocmask ( int how, const sigset_t *set, sigset_t *oset )
how:指明改变信号集的方式
SIG_BLOCK: 结果是当前集与实参set所指向的信号集的联合
SIG_UNBLOCK:结果集是当前集与实参set所指向的信号集的补集的交
SIG_SETMASK: 结果集是实参set所指向的信号集
set:指向要用来改变当前被阻塞的信号集 oset: 存储当前的掩码
3.3.7杀线程
说明：此函数和前面介绍过的杀线程信号并不完全一样，源线程是通过看是否有向目的线程发信号的权限，如果有的话就杀掉它
intkill ( pid_t pid, int signo )
pid: 目标线程 signo: 所要发的信号
3.3.8等待信号的线程队列
说明：由于线程间通信不一定同步的原因，调用此函数创建信号等待队列是十分有必要的。
int sigqueue( pid_t pid, int signo, const union sigval value )
3.3.9等待内部信号
说明：OSKit将信号分为内部信号和外部信号，这是十分有意义的，因为很多情况下，它们的处理方式是不一样的，有的外部消息可以不加理睬，但一般来说，内部消息是一定要及时响应的，系统通过调用下面的函数实现了等待一个内部信号，一旦等到，马上响应。
oskit_error_toskit_sigwait_internal ( const sigset_t *set,siginfo_t
*info,constoskit_timespec_t *timeout )
sigset_t: 信号装置，无符号整型
siginfo_t:信号信息不会被外部的信号打断
3.3.10线程等待信号
说明：在线程调度时，调度程序经常会发送此信号让执行完毕的线程等待还没执行完的线程，这是为了保持线程之间的同步。
intsigwait ( const sigset_t *set, int *sig )
3.3.11 线程等待信号(一般指内部信号)
说明：同样的，核心内的线程一样也要保持同步。
intsigwaitinfo ( const sigset_t *set, siginfo_t *info )
3.3.12线程等待信号(有时间限制)
说明：此外为了完善系统的线程管理，OSKit还提供了这条函数，用来设定线程的等待时间，如果在规定的时间内没有信号到来的话，则不再等待。
intsigtimedwait ( const sigset_t *set,siginfo_t *info,
const structoskit_timespec *timeout )
3.3.13线程等待信号，如果无信号发给它，则无限期等待
说明：但有的时候，线程要等待的信号对于该线程来说是十分重要的，所以它将无限期的等待下去，同时调度程序会将该线程阻塞起来。
intsigsuspend ( const sigset_t *sigmask)
3.3.14从一个陷入发送信号给线程
说明：当系统内部发生陷入的时候，系统会给正在执行的线程发送信号，OSKit正是调用了此函数来实现。
voidoskit_libc_sendsig ( int sig, int code, struct sigcontext *scp )
3.3.15发出线程阻塞信号
说明：如果当前正在执行的线程由于某种突发情况被阻塞了，它将调用此函数，来通知与其相关的线程。
voidoskit_deliver_pending_signals ( void )
3.3.16不会被阻塞的信号发送
说明：在操作系统中，有许多十分重要的消息是不能被阻塞的，OSKit所提供的此条函数调用便是用来发送此种信号的。
voidreally_deliver_signal ( int sig, siginfo_t *info, struct sigcontext *scp )
3.3.17信号初始化
说明：与线程类似，信号并不是从天而降，它也要先进行初始化，然后再发送给接受线程。
voidpthread_init_signals ( )
3.4 pthreads/pthread_cond.c
此源码文件包括了一套完整的线程通信的条件变量，它是线程通信的重要组成部分，通过阅读下面的函数分析，将使读者了解OSKit到底是用什么函数来具体实现线程通信的条件变量。
3.4.1条件变量的初始化数据结构
说明：在OSKit的线程间通信机制中，经常用到条件变量。所谓条件变量，就是两个线程通过条件变量来达到同步。例如，A线程我们让它等待一个条件变量，B线程我们让它发送一个信号，满足A线程所等待的条件，这样就实现了A、B线程之间的同步。
intpthread_cond_init ( pthread_cond_t *c, const pthread_condattr_t *attr)
pthread_cond_t: 条件变量 pthread_condattr_t: 条件变量属性
3.4.2撤销条件变量
说明：条件变量并不是永远发生作用的，所以有创建就得有撤销，OSKit正是调用了这个函数来实现条件变量撤销。
intpthread_cond_destroy(pthread_cond_t *c)
3.4.3线程等待条件变量
说明：OSKit设定条件变量就是为了通过让线程等待它，从而实现线程之间的相互协调。
intpthread_cond_wait ( pthread_cond_t *c, pthread_mutex_t *m)
pthread_mutex_t：为什么而等待
3.4.4安全的等待
说明：等待条件变量的方式也是多种多样，此函数提供的是一种安全的等待方式，即等待条件变量的线程不会被中断。
intpthread_cond_wait_safe ( pthread_cond_t *c, pthread_mutex_t *m )
注：不会被中断
3.4.5等待条件变量，但有时间限制
说明：另一种等待条件变量的方式是在一定的时间限制内等待，一旦超时，线程便放弃对该条件变量的请求。
intpthread_cond_timedwait ( pthread_cond_t *c, pthread_mutex_t
*m,oskit_timespec_t *abstime )
struct oskit_timespec{
oskit_time_t tv_sec; /* 秒 */
oskit_s32_t tv_nsec; /* 纳秒*/
};
3.4.6等待捐赠条件
说明：在操作系统中线程之间总有一些比较有趣的调度算法，捐赠就是其中之一，在OSKit里，出于同一个等待目的的线程之间，为了总体上的最优化，某些线程可以将自己占有的资源捐赠给其他线程，让其尽早满足执行的条件。
intpthread_cond_donate_wait ( pthread_cond_t *c, pthread_mutex_t
*m,oskit_timespec_t *abstime, pthread_t donee_tid )
pthread_tdonee_tid：被捐赠线程号
3.4.7等待条件超时
说明：此函数是OSKit的出错信息，它是在等待条件变量超时的情况下才被调用的。
oskit_error_tpthread_condwait_timeout ( struct oskit_iunknown *listener, void *arg )
3.4.8线程发送信号条件
说明：在线程间通信中，线程并不是什么时候都可以发送信号的，OSKit定义了下面这个函数，规定了信号发送是所要等待的条件；换句话说就是只有满足了此函数调用所设定的条件，线程之间才可进行通信。
intpthread_cond_signal ( pthread_cond_t *c )
3.4.9线程广播条件
说明：有些时候，某些线程需要对系统中所有的线程发送同一条消息，这样就用到了OSKit提供的线程广播的函数。
intpthread_cond_broadcast ( pthread_cond_t *c )
本 章 小 结
本章从线程间的两种通信机制入手，系统地阐述了OSKit的线程通信机制。
在第一节主要描述了OSKit所用到的两种线程间通信机制，以及它为什么没有使用UNIX中的管道通信，另外，我还以表格的形式详细列出了OSKit提供的各种信号量、以及它们与POSIX标准之间的关系。第二节中以源代码中的/pthreads/pthread_ipc.c 为例，说明了第一节中消息队列的具体实现。第三节以源代码中的 /pthreads/pthread_signal.c为例，说明了Oskit第一节中信号量的具体实现。第四节中又以源代码/pthreads/pthread_cond.c为例，阐述了条件变量的概念以及用条件变量进行辅助通信的具体实现。
OSKit的线程机制 第四章2000年12月25日22:20
作 者： 汤海京
导师：陈朔鹰
第四章 线程调度
线程调度是操作系统内核中的主要内容之一，它对整个操作系统的执行效率至关重要。OSKit当然也包括此项内容，而且由于线程的调度更加频繁，所以调度成学这部分在操作系统中的比重要比它在UNIX中大许多。
4.1 线程调度算法分析
4.1.1 线程调度算法的总体描述
在分时系统中，内核给每个线程分配一段CPU时间，这段时间称为时间片，当这段时间过去之后，内核将调度另一个线程让其变为执行态。这就是所谓的时间片轮转法。
与UNIX中的线程调度十分相似的是，OSKit的调度程序也采用了一种被称为多级反馈循环调度，此种算法属于操作系统调度程序中最常用的一种。其核心思想是：内核给线程分一个时间片，并把该线程反馈回若干优先级队列中的某一个。一个线程在结束它之前，可能需要多次通过多次的"反馈循环"。当内核作上下文切换和恢复的时候，调度程序必须保证该线程从原来挂起的地方继续执行，否则这种调度算法是不能采用的。
因此，我认为有必要向大家重申一下线程的上下文切换和恢复。首先，所谓线程的上下文是指由用户地址空间的内容、硬件寄存器的内容以及与该线程有关的内核数据结构组成的。更加严格的讲，线程的上下文是由它的用户级上下文、寄存器上下文以及系统级上下文组成。
4.1.2 优先级逆转法
OSKit中采用了操作系统设计中比较精彩的优先级逆转算法，即在一个优先级较低的线程占有mutex的同时，另一个优先级较高的线程又来申请此mutex，这样，优先级较高的线程就被比他低的线程阻塞。
此时我们引入了优先级逆转算法，也就是说，当上述情况发生的时候，线程调度程序就将优先级较低的线程的优先级提升至与较高优先级线程一样，这样可以使得占有mutex的线程快速执行。
如果现在需要调度的线程不止两个的话，该算法允许进行递归，也就是说，那个优先级低的线程执行还需要另外一个mutex，而此mutex被另一个优先级更低的线程占有，所以，调度程序就依次提升优先级低的线程的优先级，这就是递归提升。
但是，如过我们支持递归提升优先级的话，就可能出现死锁，所以我们又必须引入一套检验死锁的程序，这大大增加了操作系统核心的大小和系统的开销，但使得操作系统更加完善，并可以处理实时线程。
4.2 pthread/pthread_scheduler.c
此源码文件包括了一套完整的线程调度机制，OSKit的全部线程调度算法都集中在了这个文件之中，通过阅读下面的函数分析，将使读者了解OSKit到底是用什么函数来具体实现线程调度的，并且能对我在前面叙述的概念的理解有所加深。
4.2.1清空等待调度的线程队列
说明：为了能让大家真正从概念上了解此函数的作用，我想有必要先说明一下什么是线程等待队列。由于调度程序在操作系统中也是作为一个线程出现的，并且同一时间，它只能调度一个线程，所以就会造成有许多线程等待调度但无法接受调度的情况，OSKit提供的这个函数正弥补了这个缺陷，他将所有的等待调度的线程用链表的形式链接在一起，这就是所谓的等待调度的线程队列。显然，清空它实际上就是释放链表的指针。
staticinline int posix_runq_empty ( void )
4.2.2得到等待队列中优先级最高的线程的优先级
说明：当调度线程完成手头的工作，要对下一个线程进行调度时，就将面临一个问题，到底应该调度哪个等待调度的线程？OSKit提供的这个函数可以返回此时在等待队列中优先级最高的线程，供调度线程调度。
staticinline int posix_runq_maxprio ( void )return PRIORITY_MAX - ( prio - 1 );
4.2.3得到指向下一个要执行线程的指针
说明：当某个线程要转执行态的时候，调度程序并不知道这个线程挂起在了什么地方，我们可以通过调用OSKit提供的这个函数来找到指向要执行线程的指针。
staticinline int posix_runq_onrunq ( pthread_thread_t *pthread )
4.2.4在线程的执行队列的队尾追加一个线程
说明：将优先级最低的线程，或者是由于其他原因要最后执行的线程添加到线程执行队列的最后。
staticinline void posix_runq_insert_tail ( pthread_thread_t *pthread )
4.2.5在线程的执行队列的队头追加一个线程
说明：将优先级最高的线程或者是由于某种原因要现执行的线程添加到线程执行队列的最前面。
staticinline void posix_runq_insert_head ( pthread_thread_t *pthread )
4.2.6将等待队列中优先级最高的线程提出队列执行
说明：当操作系统要执行在线程执行队列里等待线程的时候，理所当然应该从头开始，我们考调有此函数来实现线程出对执行的功能。
staticinline pthread_thread_t * posix_runq_dequeue ( void )
注： 返回指向下一个等待线程的指针
4.2.7从等待队列中删除独占资源的线程
说明：为了使操作系统能够在总体最优化的前提下运行，OSKit规定不允许某一个线程长时间独占系统资源，如果发现此类时间，就可以调用这个函数来将独占资源的线程从执行队列中删除，以保持线程调度的公平合理。
staticinline void posix_runq_remove ( pthread_thread_t *pthread )
4.2.8此时用到的调度算法
说明：在前面的章节里，我曾经提到，线程的调度算法仿佛其属性一样，在初始化的时候就赋给了它，但它却是可以更改的，OSKit就是通过调用下面的这个函数来实现在线程创建之后来改变调度算法的。
intposix_sched_schedules ( int policy )
if ( policy == SCHED_RR || policy ==SCHED_FIFO )
return 1;
return 0;
4.2.9将一个线程变为运行态
说明：众所周知，线程在系统中一般有三种状态，OSKit通过调用该函数实现线程转执行态的功能。
intposix_sched_setrunnable ( pthread_thread_t *pthread )
4.2.10终止该线程目前的调度算法
说明：这又是在线程创建之后改变其调度算法的一种函数调用，它的功能是中止该线程目前的调度算法。
voidposix_sched_disassociate ( pthread_thread_t *pthread )
{
if(posix_runq_onrunq(pthread)) {
/* * On the scheduler queue, so its notrunning. */
posix_runq_remove ( pthread );
}
}
4.2.11为一个新的线程创建调度参数
说明：所谓调度参数就是调度程序决定是否执行某个线程的依据。例如，某用户态线程最近使用CPU时间的统计等。
voidposix_sched_init_schedstate ( pthread_thread_t *pthread,const struct sched_param*param )
4.2.12改变线程的调度状态
说明：如果其调度参数符合调度条件，调度程序会通过调用OSKit提供这个函数来改变此线程的调度状态，并将它转为准备调度态。此时该线程被锁住，而且要关中断
intposix_sched_change_state ( pthread_thread_t *pthread , const struct sched_param*param )
4.2.13优先级迁移
说明：这是我在上面提到的优先级逆转法的具体实现，OSKit就是通过调用它来完成对线程优先级的动态变更的。
intposix_sched_priority_bump ( pthread_thread_t *pthread, int newprio)
注意：这只是暂时的，仅仅适用于实时线程
4.2.14基于某种原因，线程被送回等待队列
说明：当线程在操作系统中执行的时候，完全有可能由于用户的原因造成当线程执行完它的时间片后返回执行队列时，位置改变了。下边是我对OSKit提供的几种改变原因的注解。
intposix_sched_dispatch ( resched_flags_t reason, pthread_thread_t *pthread)
switch (reason) {
case RESCHED_USERYIELD:posix_runq_insert_tail(pthread);
/* 如果由用户造成线程为空闲态，则插入队尾 */
caseRESCHED_YIELD: posix_runq_insert_head(pthread);
/* 如果由用户造成线程为空闲态，则插入队尾*/
case RESCHED_PREEMPT:
/* 根据线程拥有的优先级和其调度算法来具体分析 */
if(pthread->policy == SCHED_RR) {
if (--pthread->ticks == 0){
posix_runq_insert_tail(pthread);
/*如果是时间片轮转发调度且只有一个ticks，则插入队尾 */
pthread->ticks =SCHED_RR_INTERVAL;
}
else
posix_runq_insert_head(pthread);
/*虽然是时间片轮转法，但拥有的ticks不止一个，则插入对头 */
}
else if (pthread->policy== SCHED_FIFO)
posix_runq_insert_head(pthread);
/*如果是先来先处理法，则插入对头 */
case RESCHED_INTERNAL: /* 使线程变为空闲态*/
default:
if (pthread == IDLETHREAD)
/*停止所有的调度算法，将线程变成空闲态 */
panic("posix_sched_dispatch:Idlethread!\n");
}
4.2.15返回优先级最高的处于等待状态的线程
说明：当调度程序要将一个出于等待状态的线程加入到执行队列中的时候，就需要有一个函数，它能返回优先级最高的等待线程，下面的函数正好就完成了这项任务。
pthread_thread_t* posix_sched_thread_next ( void )
{ if ( posix_runq_empty( ))
return 0;
return posix_runq_dequeue( );
}
4.2.16改变线程的优先级
说明：实质是将线程从队列中删除，重新赋给优先级，再插入到队尾。
OSKIT_INLINEvoid threads_change_priority (pthread_thread_t *pthread, int newprio)
4.2.17优先级继承
说明：所谓优先级继承，其理论的实质就是所有出于等待状态的线程，在等待过程中，它的优先级会随时间的推移慢慢提高。
voidpthread_priority_inherit ( pthread_thread_t *pwaiting_for )
4.2.18不继承优先级
说明：这其实与上一个优先级继承正好相反，无论等待了多长时间，线程的优先级都不会因此而改变。
voidpthread_priority_uninherit ( pthread_thread_t *punblocked )
4.2.19优先级递减
说明：如果一个线程总是处于执行状态，则出于总体最优化的考虑，OSKit会调用此函数将其优先级逐步递减，从而使得更多的线程有被执行的可能。
voidpthread_priority_decreasing_recompute ( pthread_thread_t *pthread)
本 章 小 结
本章从线程调度的一般性概括到具体实现，系统地阐述了OSKit的线程调度机制。
在第一节主要是对一般的线程调度概念的描述，并且对OSKit中最为精彩的优先级逆转法的理论作了详细的论述。第二节中以源代码中的pthreads/pthread_scheduler.c为例，从等待调度的线程队列、线程的执行队列到优先级继承、优先级递减等，完整的阐明了OSKit的线程调度机制。
OSKit的线程机制 第五章2000年12月25日22:31
作 者： 汤海京
导师：陈朔鹰
第五章 OSKit的应用实例 一个简单系统的设计与实现
5.1设计目的
OSKit是一个用来帮助我们研发操作系统的工具，如果你想更好的掌握它，除了对其本身进行分析之外，还有一个更加实际的方法，那就是利用这个工具开发一个我们自己的操作系统。
我们开发这个系统的初衷主要是为了学习，因此并没有想把它设计成像Windows、UNIX那么复杂。我们的目标是很明确的，那就是在大致搞明白OSKit应当如何使用之后，做一次尝试，用较短的时间，设计出一个具有一些最基本功能的系统。这对于我们课题组的每名成员来说，都意味着挑战。
5.2系统的功能
这个系统支持些什么？这是在开始设计之前我们要首先确定的一个问题。下面列出了一些我们希望实现的功能。
通过Multiboot或者LILO进行系统引导：这个系统可以通过所有支持Multiboot的引导程序进行引导，或者通过引导Linux的LILO进行引导。引导方式可以根据用户的要求，选择是通过软盘还是硬盘。
多线程：用户可以通过我们提供的系统调用，创建或杀死自己的线程。由于并不支持文件系统，因此新的线程恐怕只能是一个函数了。从理论上讲，我们可以让这个系统支持很多线程，但因为这仅仅是一个简单的演示性系统，因此我们把线程数限制在32个，当然这个数字也可根据用户的需求任意更改。
进程间通信：这个系统可以支持一些简单的进程间通信机制，比如信号量、消息队列等等。
外设：在众多的外设之中，我们选择了应用范围比较广的串口。利用目前OSKit所提供的机制，支持更多的设备是不成问题的，但加在这个系统中意义并不十分的大。另外，需要强调的是，访问串口的方法，是由我们自己规定，不允许用户更改。
简单的内存管理：应用程序需要的内存可以通过malloc函数动态申请。
总体构想
在该操作系统中，我们规定用户只能创建用户级线程，所有对于核心的操作都将由系统来完成。线程采用RR调度算法，也就是时间片轮转法，并允许抢占，线程在该系统中有四种状态，它们是运行态、阻塞态、睡眠态和就绪态，用户可以设定和改变线程的优先级。在线程中用户可以动态申请内存，但是需要由用户来释放。线程间提供简单的通信机制，包括信号量和消息队列。
在设备方面，对于终端，本系统将提供简单的输入输出功能。而对于串口的功能，本系统可以完整的实现，也就是说，用户既可以从串口读也可以向串口写。
为了方便起见，我们为这个系统起一个很简单的名字，叫acos，这个名字并没有什么实际的意义，仅仅为了叫起来方便。
虽然OSKit已经为我们提供了很多设计操作系统所必须的功能，比如内存分配中的malloc函数，通过Multiboot引导等等。然而，仍有许多工作是要由我们自己完成。
5.3 我们自己所完成的工作：
5.3.1 系统的启动
这里我们所说的系统启动，并不是指通常人们所说的通过软盘或硬盘引导，而是在引导结束之后，操作系统的核心进程如何启动第一个用户进程。通常，在UNIX系统中，内核启动之后，内核程序会去执行文件系统上的init程序，这个程序是整个操作系统中的第一个用户进程，剩下的进程，都必须通过这个进程才能启动。在acos中，我们规定，用户必须要提供一个acos_init() 函数，系统在启动初始化工作全部完成之后，acos_init( )函数将被作为系统中的第一个进程启动。这之后的工作，就完全由用户来完成了。
当进程acos_init( ) 结束时，整个系统也将终止运行。
在acos_init( )启动之前，究竟还有哪些事情需要做呢？下面我们就列出要做的事情：
对整个系统进行初始化，注册设备，检测设备，初始化设备需要的数据结构，初始化线程库，创建线程需要的数据结构。
5.3.2 线程管理
所谓操作系统的线程管理，一般包括了一下的三大部分：线程的创建，线程间通信和线程调度。
线程的创建包括了初始化线程和创建线程的属性。
线程间通信中，我们使用了信号量，条件变量。
在线程调度中，用户线程只能使用时间片轮转法作为调度算法，并且规定在调度过程中调度算法不允许更改。
5.3.3 外设（串口）
在UNIX系统中，所有的设备都可以通过文件系统进行访问，读、写设备就像读写文件一样。在我们设计的这个acos中，并没有对文件系统提供支持，也不提供像读写文件系统一样的方法来访问设备。但是，我们提供一套基本的函数，供用户线程对串口进行读写操作，这些函数专门用于处理串口。
一个设备在同一时刻只能被一个线程使用，因此，在使用设备以前要申请，只有申请成功的线程才能够使用设备。
5.4 用户手册
5.4.1 安装
用户需要在Linux下键入 tar -zxvf acos-0.0.1.tar.gz 。
./setup,详细的安装信息请参见README文件。
进入usr/local/bin/acos之后，根据我们所提供的API手册编写自己的应用程序，然后将这些应用程序的源文件编译成一个"filename.o",用户通过执行acbuildfilename.o命令将应用程序链入操作系统内核，根据你所使用的核心格式执行mkXXXimage命令生成所需要的核心映像，选择恰当的装入程序装入启动核心映像。
5.4.2 用户编程接口
如果您对操作系统的概念有所了解，并详细阅读了我们为您提供的技术文档之后，便可以利用用户编程接口自行开发了。以下我将向各位详细介绍每个接口所提供的功能，希望对您能有所帮助。
一、管理线程的API
1.1 初始化线程
ac_init_pthreads( );
1.2 线程创建
ac_thread_create ( void *name, void *arg,
int *out_thread_id);
1.3 设置线程的优先级
ac_thread_setprio(int thread_id, int pri);
1.4 撤销线程
ac_thread_cancel(int thread_id);
1.5 线程休眠
ac_thread_sleep(ac_s64_t millisecond);
1.6 将该线程与某一个线程相关联
ac_thread_join(int tid, void **status);
1.7 撤销该线程与某线程的关联
pthread_attr_setdetachstate ( pthread_attr_t *attr, intdetachstate )
二、管理互斥量的API
2.1 初始化互斥量
ac_mutex_init ( ac_pthread_mutex_t* mutex,
ac_pthread_mutexattr_t* attr);
2.2 设置互斥量协议
ac_mutexattr_setprotocol ( ac_pthread_mutexattr_t* attr, intprotocol);
2.3 设置互斥量类型
ac_mutexattr_settype ( ac_pthread_mutexattr_t* attr, inttype);
2.4初始化互斥量属性
ac_mutexattr_init(ac_pthread_mutexattr_t* attr);
2.5互斥量加锁
ac_mutex_lock(ac_pthread_mutex_t *mutex);
2.6互斥量解锁
ac_mutex_unlock(ac_pthread_mutex_t *mutex);
2.7撤销互斥量
ac_mutex_destroy(ac_pthread_mutex_t *mutex);
三、管理IPC的API
3.1消息发送（ IPC机制 ）
ac_ipc_send ( int thread_id, void* msg,ac_size_tmsgsize,ac_s32_t timeout);
3.2消息接受（ IPC机制 ）
ac_ipc_recv(int thread_id, void* msg,ac_size_tmsgsize,ac_size_t *actual, ac_s32_t timeout);
3.3消息等待（ IPC机制 ）
ac_ipc_wait(int *src_id, void *msg,ac_size_tmsgsize,ac_size_t *actual, ac_s32_t timeout);
3.4接受同步消息
ac_ipc_reply(int desthread, void *msg, ac_size_t msg_size);
3.5发送同步消息
ac_ipc_call(int dst, void *send_msg, ac_size_tsend_msg_size,
void *recv_msg, ac_size_t recv_msg_size,
ac_size_t*actual,ac_s32_t timeout);
四、管理条件变量的API
4.1条件变量初始化
ac_cond_init(ac_pthread_cond_t *cond, ac_pthread_condattr_t*attr);
4.2某线程等待条件变量
ac_cond_wait(ac_pthread_cond_t *cond, ac_pthread_mutex_t*mutex);
4.3唤醒等待该条件变量的线程
ac_cond_signal(ac_pthread_cond_t *cond);
4.4符合条件变量的线程广播
ac_cond_broacast(ac_pthread_cond_t *cond);
五、硬件部分
5.1打开串口
ac_serial_open(int serial_num, ac_u32_t flags);
5.2监听串口
ac_serial_listen(int serial_num, ac_u32_t flags);
5.3关闭串口
ac_serial_close(ac_ttystream_t* a_stream);
5.4从串口读
ac_serial_read(ac_ttystream_t* s, void *buf, ac_u32_t len,ac_u32_t*out_actual);
5.5往串口写
ac_serial_write(ac_ttystream_t* s, const void *buf,ac_u32_t len,ac_u32_t *out_actual);
5.4.3 应用程序示例
为了能让各位老师对我们的演示系统一目了然，我们特地选取了在操作系统中比较有代表性的4个例子供大家欣赏，它们是，哲学家算法，时钟演示，线程调度和中断响应。
所需的资源：演示前三个例子需要一台intel386或更新的计算机，一张1.44MB的软盘；演示第四个例子除了上述设备之外，还需要一根串口线，一台装有Windows9x的计算机作发送机，并在其上安装有能向串口发送信息的软件。
1.哲学家算法
哲学家算法也称哲学家进餐的同步问题，最早是在1965年由Dijkstra提出并解决的。下面我就简单描述一下这个经典IPC问题的大意：7个哲学家围坐在一张圆桌周围，每个哲学家面前有一个碟通心面，由于面条很滑，所以要用两把叉子才能夹住。相邻两个碟子之间有一把叉子。哲学家的生活包括三种状态：即吃饭，思考和挨饿，当一个哲学家觉得饿时，他试图分两次去取他左边和右边的叉子，每次拿一把，但不分次序。如果成功地获得了两把叉子，他就开始吃饭，吃完以后放下叉子继续思考。这里的问题是：为每一个哲学家写一段程序来描述起行为，要求不能死锁。
在这个例子中我们设定了7个哲学家，且不允许哲学家饿死。我们为每个哲学家创建一个线程，把叉子看作条件变量，让线程等待条件变量，如果满足条件，则线程执行(哲学家的吃饭状态)，执行一定时间之后，释放条件变量，进入休眠状态（哲学家的思考状态），当休眠时间过去之后，线程被唤醒，重新等待条件变量（哲学家的挨饿状态）。
2．时钟演示
计算机是以严格精确的时间进行数值运算和数据处理的，最基本的时间单元是时钟周期，OSKit最小可以精确到纳秒一级，其时钟系统的特点是允许在系统时钟之上创建自己的时钟，用于控制周期性线程。
我们的演示系统的源代码看似比较简单，但实际上却是建立在一个庞大的时间系统之上的，这个时间系统是整个操作系统活动的动力。
我们的演示程序将演示控制计算机的时钟计时( 每400毫秒显示一次 )，计时10次后返回初始菜单。
3．线程调度
在此个演示程序中，一开始有两个线程，它们所采取的调度算法是时间片轮转法，与此同时还有一个优先级最高的线程在休眠，它每400毫秒睡醒一次，打断此时处于运行状态的线程，那个优先级最高的线程转执行态，等它执行完它的时间片之后，前两个线程继续执行。
4．中断响应
这个例子演示了操作系统对外设的支持，我们选择了串口。演示这个例子，需要两台计算机和一根串口线，其中一台计算机安装我们的演示系统，另一台需要有一个向串口发送信息的软件，此软件我们是用Delphi编写的，运行在Windows98系统下，两台计算机用我们自己制作的串口线相连。演示程序的一开始，有两个优先级相同的线程在时间片轮转。当我们从另一台装有Windows98的机器上给演示机发送信息时，原来处于运行状态的两个线程被中断，演示机会成功的收到发送机发送的信息，然后等待操作人员的处理，是否继续运行该例子或者退出。
本 章 小 结
本章是为最后提供给各位老师欣赏的演示系统所写的，针对每个例子，先从理论上论述了它的概念以及我们是怎么实现的，然后附上了部分程序。
注意：由于演示系统所使用的OSKit的系统调用基本在前三章已经逐一做了详细的介绍。
OSKit的线程机制 第六章2000年12月25日22:34
作 者： 汤海京
导师：陈朔鹰
第六章 结束语
OSKit的线程机制既遵照了POSIX标准，又在一些地方有所突破，诸如实时部分，这些都是开发人员对操作系统以及自由软件的贡献。
OSKit虽然还有许多的不足，但由于它出现在Linux之后，所以其许多设计思想弥补了Linux中的不足（比如在线程通信部份OSKit就没有照搬Linux，而是扬长避短，去掉了管道型通信方式），而又由于OSKit每三个月更新一次，不断的增加一些新的算法和设计思路（如对实时操作系统的支持，这在Linux下是很少出现的，这是因为Linux的设计者们并不认为实时操作在单机系统的日常应用中能占多大的比重，但OSKit的设计者们从操作系统完整性的角度出发，为我们提供了许多实时的系统调用），这使得它总能站在操作系统设计的最前沿。
其实，自由软件的魅力远远超过了微软的视窗，但现在的开发人员总是把一部分精力集中在了对kernel的裁剪之上，而OSKit的出现恰恰弥补了这项缺陷，仿佛为自由软件事业的腾飞插上了一双翅膀，使得我们更加有理由相信自由软件事业终将蓬勃发展。
OSKit在美国的一些大学里已经得到了的应有的重视，并有一个研究组用OSKit开发完成了一个JAVAOS,而且在美国犹它大学计算机科学系FLUX研究组的主页上，还有一个专门的链接，里面都是用OSKit开发的项目简介，可见其已经有了一定的用途。但在中国的大学里，了解程度还远远不够，据我们所知，目前只有中科院的一个课题组用OSKit完成了一个小型的操作系统。
众所周知，国内在自由软件领域的成就是远远落后于国外的，所以我们课题组对OSKit做了一定的分析和探索，算是抛砖引玉，希望国内操作系统的爱好者们能给予充分重视。让我们共同努力，推进中国自由软件事业的发展。
后 记
以上是我对我们课题组所做研究工作，以及我个人工作的介绍。通过几个月以来我对OSKit的分析和研究，加深了对操作系统原理的认识，并对其实现有了具体的认识，提高了我的分析能力，丰富了实践经验。
我衷心地感谢我的导师陈朔鹰老师给予我的悉心指导，张丽芬以及赵小林老师也给予我们课题组以热心的帮助，我们对901教研室的全体老师表示衷心的感谢。
参考文献
·OSKIT文档：http://www.cs.utah.edu/projects/flux/oskit/
·《操作系统的设计与实现》,北京理工大学出版社，张丽芬著
·《COM原理与应用》，清华大学出版社，潘爱民著
·《计算机环境的可移植操作系统界面POSIX.1》,电子工业出版社，中软总公司第二开发部译
·《Linux操作系统内核分析》，人民邮电出版社，陈莉君编著
·《Linux编程白皮书》，机械工业出版社，（美）David A.Rusling等著，朱珂等译
·《操作系统︰设计与实现（第二版）》，OPERATING SYSTEMS Design and Implementation（SecondEdition）,电子工业出版社,ANDREW S.TANENBAUM,ALBERT S. WOODUHULL 著，王鹏，尤晋元，朱鹏，敖青云译校
·《UNIX操作系统设计与实现》电子工业出版社，李建国主编
·《UNIX操作系统设计》The Design of the UNIX Operation System,机械工业出版社，（美）Maurice J.Bsvh 著 王旭等译
·《实用UNIX编程》, 机械工业出版社，（美）Kay A. Robbins,Steven Robbins 著，刘宗田等译
·《Advance Programming in the UNIX Environment》,(美) W. Richard Stevens
·《Linux 上的C 编程》，中国电力出版社，怀石工作室编著
·《Linux从入门到精通》，The Linux A-Z,电子工业出版社，（英）Phil Cornes 著,童寿彬等译，夏道藏审校
·《Linux 操作系统及实验教程》，机械工业出版社，李善平等编著
·《Linux 常用技术大全》，Linux Complete,电子工业出版社，（美） Grant Taylor 著，邱仲潘等译
·《计算机操作系统原理与技术》,西安交通大学出版社，陆丽娜，齐勇，白恩华主编
·《UNIX通信与Internet》,UNIX Communications and the Internet (第三版)，沈奇，王健 李玲等译
·《Linux权威指南》，中国电力出版社，怀石工作室编著
·《Using Threads in Interactive Systems:A Case Study》, HASUDR, C., JACOBI,C.,THEIMER
·《POSIX Programmer's Guide》,O'Reilly, LEWINE
作 者： 洪宁
导师：陈朔鹰
目录
----------------------------------------------
前言
第一章 OSKIT介绍
1.1 OSKIT概述
1.2 OSKIT的组成
1.3 OSKIT的设计原则
1.4 OSKIT的配置
1.5 OSKIT的编译
1.6 OSKIT的使用
1.7 OSKit的执行环境
第二章 COM规范介绍
2.1 COM的基本概念
2.1.1 组件技术
2.1.2 什么是COM
2.1.3 COM结构
2.1.4客户/服务器模型
2.2 COM对象
2.2.1 COM对象的标识－CLSID
2.3 COM接口
2.3.1 接口的定义和标识
2.3.2 接口的一些特点
2.4 Iunknown接口
2.4.1 引用计数
2.4.2 实现引用计数
2.4.3 接口查询
2.4.4 COM对象的接口原则
2.5 COM特性
2.5.1语言无关性
2.5.2 进程透明特性
2.5.3 可重用性
第三章 OSKIT中COM机制的实现
3.1 OSKIT中COM的基本定义
3.2 实例分析Iunknown接口的实现
3.2.1 C环境对象的结构
3.2.2 C环境接口及其对Iunknown接口的实现
第四章 OSKIT中的接口注册机制
4.1 概述
4.2 数据库对象
4.3 服务接口的定义
4.4 数据库服务接口的实现
4.4.1 创建数据库
4.4.2 在数据库中注册接口
4.4.3 在数据库中注销接口
4.4.4 查找用某iid注册的第一个接口
4.4.5 查找用某iid注册的所有接口
4.4.6 克隆数据库
第五章 OSKIT的启动及系统初始化
5.1 概述
5.2 核心装入程序－Multiboot
5.2.1 Multiboot简介
5.2.2 Multiboot规范
5.2.3 Multiboot进行初始化的步骤
5.3 OSKIT中软件环境的初始化
5.3.1 软件环境初始化的步骤
5.3.2 软件环境初始化的实现
第六章OSKit的应用实例：一个简单系统的设计与实现
6.1设计目的
6.2系统的功能
6.3我们自己所完成的工作：
6.3.1系统的启动
6.3.2线程管理
6.3.3 外设（串口）
6.3.4 应用程序示例
第七章 结束语
后 记
参考文献
OSKit的部件对象模型 前言2000年11月30日19:38
作 者： 洪宁
导师：陈朔鹰
课题名称：基于面向对象的操作系统开发平台(OSKit)的分析与程序设计
课题来源：自拟题目
如果说自由软件的出现是一个偶然的话，那么，席卷全球的Linux热潮则是一个奇迹，他正以势不可挡的趋势迅猛发展，其前途不可限量。
Linux内核源代码的开放给希望深入操作系统内部世界的人们提供了可能，但随之而来的问题是，当我们要开发自己的操作系统时，由谁来读系统的kernel部分呢。对这部分的处理从逻辑上分析不外忽三种方式：全部保留，对其进行裁减，全部推倒重来，很显然，最后一种方法是不可能的，而如果我们采用的是第一种方法，其结果当然一定可以满足我们的要求，但是，最后编译出来的核心将十分的庞大，尤其是对嵌入式操作系统的开发者来说，是不能忍受的，所以，大多数开发者采用的第二条路。
但是，第二条路也非平坦的大道，道理很简单，你要想对kernel进行裁减，首先你应该将全部的源代码阅读一遍，并且将其中的相关性理顺，然后才能谈到裁减，所以工作量也十分的庞大。
然而，OSKit的出现改变了这一切，它使得我们不需要将精力集中在kernel源代码的阅读上，因为kernel部分的源程序已经由OSKit的开发人员替你分析过了，他们将源码全部模块化，并将所有模块之间的相关性写在了文档之中，呈现在你的面前，这与你自己分析源代码的结果是一样的。
OSKit最本质的东西和Linux一样，体现在"自由"和"开放"的思想，"自由"意味着世界范围内的知识共享，由于OSKit出现在Linux之后，其设计思想继承了Linux的精髓，所以说它的出现并不完全是美国犹它大学计算机科学系FLUX研究组的功劳，而应该是"自由"的结果。"开放"则意味着OSKit对所有的人都敞开大门，在这种开放而自由的天地里，你可以中分发挥自己的创造才能。
在后面的几章里，我将向大家系统地介绍我的全部研究成果-OSKit的COM机制及初始化过程，希望读者能在最短的时间内了解OSKit，更希望大家能本着"自由"与"开放"的精神加入到我们的研究中来，为中国的自由软件事业贡献自己的一份热情。
由于本人能力有限，论文中的有些术语表达可能不妥，内容也可能不够准确，敬请各位老师和同学批评指正，本人不胜感激。
这篇论文主要论述了四部分内容：
第一部分：OSKit简介
第二部分：COM规范介绍
第三部分：OSKit中COM机制的实现
第四部分：OSKit的启动及初始化过程
洪宁2000年6月19日
OSKit的部件对象模型 第一章2000年11月30日19:55
作 者： 洪宁
导师：陈朔鹰
第一章 OSKIT介绍
1.1 OSKIT概述
OSKIT是美国犹它大学计算机科学系FLUX研究组编写的一套用于架构操作系统内核、服务器和其他OS级软件的框架及模块化的部件和库程序。OSKIT的编写者认为，操作系统中有很大一部分模块是系统必须的，但并不是开发者所感兴趣的，例如系统装入模块，各种标准驱动模块等。使用OSKIT的目的就是使操作系统的开发者集中精力开发他们操作系统中有特色的，或者他们感兴趣的部分，而不必考虑一些繁琐而乏味的细节。为了达到这个目的，OSKit在设计时借用了COM的思想，把操作系统的各个部分设计成尽量独立的COM模块，以方便操作系统的开发者使用或替换。因此，当开发人员使用这套工具时，可以把它当作一个完整的操作系统来使用，也可以根据需要使用其中的一部分，它还可以作为一套动态链接库，由操作系统及支持程序对它进行调用。
1.2OSKIT的组成
OSKIT把给开发者提供的功能分为三个部分：接口、函数库和部件库。
OSKIT的接口非常清晰，而且是面向对象的，它采用了部件对象模型（COM）的架构，在文章的后续部分会对OSKIT中的COM接口的组织和结构进行详细的讨论。
OSKIT的函数库使用传统的C语言，并采用面向函数的方式向用户提供服务。例如基本的C库函数，这些函数易于使用和控制，目标操作系统能很方便的使用其中的某个函数，而且各个函数之间的依赖关系已被缩减至最小。这些函数库中很少使用OSKit自己的COM接口，取而代之的是在普通的C头文件中定义面向函数的接口。这种设计策略为操作系统设计人员提供了最大程度的支持和灵活性，以适合任何特殊的操作系统环境。
下面是OSKIT目前提供的主要函数库列表，以及它们的简介：
liboskit_c：一个简单的最小限度的C库，它在一个受限制的OS环境中提供了通用的C库支持，并使对环境和其他模块的依赖达到最小限度。在需要一个更完整的、类POSIX的C函数库的情况下，可以使用FreeBSD的C函数库，甚至是用自己编写的函数库来代替这个最小化的C库。
liboskit_kern：建立一个基本的操作系统内核运行环境所需的内核支持代码，该函数库为陷入和中断等提供缺省的处理程序。这个库包括很多在写核心代码时非常有用的通用工具，如访问某个CPU寄存器，建立并维护页表，在不同的处理器模式间转换等。
liboskit_smp：内核支持代码，这个库可建立一个便于操作系统使用的多处理器系统环境。
liboskit_com：处理COM接口的工具函数和一套通用的包装部件。
liboskit_dev：这个库提供了驱动程序和由其它操作系统引入的部件（如网络、文件系统）在OSKit中使用时所需要的转换函数的缺省实现，这些函数工作在OSKit驱动程序框架之中。这些函数的缺省实现是为使用了liboskit_kern库的简单内核所设计的，开发者在必要时可以重写部分或全部函数。
OSKIT的部件库提供了一个一般情况下更高层的功能，这种功能以一种更加标准、精心修整的、面向对象的"黑盒"方式设计。尽管OSKit的"部件"缺省情况下也是被打包成为普通的链接库，但它们的结构则是被设计成面向对象的，而不是传统的面向函数的方式。与OSKit的函数库相比，部件库通常只对外开放一些相关的公用调用接口，而不是大量的功能。例如，在Linux和BSD驱动程序部件库，每一个完整的驱动程序仅实现成为一个单独的函数调用，这个调用用来初始化并注册驱动程序。目标系统通过OSKit的面向对象的COM接口来与这些部件进行交互，这允许很多部件及部件的实例共存，并以操作系统开发人员定义的方式交互。这种设计的策略有利于将已有系统（如BSD和Linux）中的代码并入OSKit，那时，隐藏原有环境的细节要比提供灵活性更重要。
下面是目前OSKit所提供的主要部件库的概要。
liboskit_posix：增加对用POSIX构造的系统通常会实现的系统调用的支持。例如：open、read和write等。这些POSIX操作被映射到相应的OSKitCOM接口上。最小化的C库和FreeBSDC库都依赖POSIX库来提供所需要的系统级操作。
liboskit_freebsd_c：源于FreeBSD的完整的类POSIXC库，提供了对单线程和多线程的支持。在需要支持类POSIX函数或线程安全时，这个库可以用来替换最小化的C库。
liboskit_freebsd_m：完整的标准数学库。可以提供浮点数支持。
liboskit_fsnamespace：文件系统名字空间库，为应用程序提供了命名接口，可以将多种部件的绝对和相对路径名转换成为oskit_file和oskit_dir的COM对象。
liboskit_rtld：运行时链接、装入库，允许ELF格式的OSKit内核装入共享库。
liboskit_lmm：一个灵活的存储管理库，它可以管理物理内存或虚拟内存。
liboskit_amm：地址映射管理库，用于管理系统资源。
liboskit_svm：简单虚存库，它使用AMM库定义了一个简单的用于单独地址空间的虚存接口，提供内存保护和为块设备如一个硬盘分区进行分页。
liboskit_threads：这个库提供了多线程的内核支持，包括POSIX线程、同步、调度和栈保护。
liboskit_diskpart：一个能够识别多种常见的磁盘分区方案并生成一个完整映射的通用库。这个库提供了一个简单的方法让操作系统可以找到它所"感兴趣的"磁盘分区。
liboskit_fsread：一个简单只读文件系统解释库，它可用于不同的文件系统，包括BSDFFS、Linuxext2fs和MINIX的文件系统。它通常与liboskit_diskpart一起使用，为操作系统提供从硬盘或软盘上读取程序和数据的功能。这个库也可用于构造装入程序。
liboskit_exec：一个通用的可执行程序解释器和装入器，它支持流行的可执行程序格式，如a.out和ELF。
liboskit_linux_fs：对Linux内核2.0.29版的文件系统部分代码进行包装。
liboskit_netbsd_fs：对NetBSD1.2版的文件系统部分代码进行包装。
liboskit_memfs：一个简单的基于内存的文件系统，对外提供了标准的OSKit文件系统接口。
liboskit_freebsd_net：对FreeBSD2.1.7.1版网络代码的包装。
liboskit_linux_dev：对Linux内核2.0.29版的设备驱动程序进行包装。将其包装在OSKit的设备驱动架构中。
liboskit_freebsd_dev：对FreeBSD2.1.7.1版的设备驱动程序进行包装。将其包装在OSKit的设备驱动架构中。
1.3OSKIT的设计原则
尽管当前OSKIT的目标平台是X86体系，但将来它会被移植到其它的体系，如StrongArm。
OSKIT的接口被尽可能地设计成便于移植。尽管很大一部分的OSKit代码是与平台相关的，但它很多的功能接口都是通用的，并且可以在很多其它的体系结构或平台上使用。例如，OSKit的设备驱动程序接口是完全可以移植的。
OSKIT在每一个库中记录模块间的依赖信息。对于函数库，这意味着要标明不同的函数间的依赖关系；对于部件库，这意味着要标明每一个库中不同部件集之间的依赖关系。
1.4OSKIT的配置
OSKit遵从GNU的配置、编译和安装习惯：可以参考源代码根目录中的INSTALL文件，在该文件中有使用GNU配置文件的通用方法。简单的说，需要运行OSKit根目录中的配置文件，这个文件将会估计出当前系统的类型以及各种所需工具（如C编译器）的位置。OSKit可以配置成在它自己的目录中编译，只要在OSKit源码的根目录中用./configure命令就可以了。或者可以将OSKit编译并安装到一个单独的目标目录中，如果需要这样，只要在那个新的目录中运行配置文件就可以了。例如，当源文件存在NFS分区上时，使用一个单独的目标目录，可让你把目标文件放在本地的硬盘上。
此外，OSKit的配置还可以保留多份（当然是在不同的目录中），每一套配置有自己的目标文件，但共享一份代码。
当需要为另一种体系结构对OSKit进行交叉编译时，需要指定宿主机（需要运行OSKit的机器）的类型和编译机（编译OSKit的机器）的类型，这可以用configure中的-build=machine和-host=machine选项来实现。由于OSKit是一个单独的软件包，并且不使用任何它自己以外的包含文件和库文件，因此宿主机的操作系统部件与OSKit的配置并没有直接的关联。然而，在配置脚本运行时会需要以对宿主机的指定作为一个前缀来寻找各种交叉编译工具。例如，如果指定"-host=i486-linux"，配置脚本会去寻找名为i486-inux-gcc、i486-linux-ar和i486-linux-ld等的编译工具。在其它工具中，具体使用哪一个工具，由目标文件的格式来决定（如ix86-linux-*工具可以建立ELF格式，而ix86-mach-*工具建立a.out格式）。
OSKit的配置脚本支持很多基本的选项，要得到一份完整的选项列表，可以运行./configure-help。除了这些基本的命令之外，配置脚本还支持下面的这些OSKit特有的选项：
-enable-debug：在编译时使用这个选项，将会把调试信息包含进来，这会影响一些运行的性能，但当错误有可能发生时，会提高检测错误的速度。
-enable-profiling：生成剖析版的OSKit库，为了与习惯的标准保持一致，剖析版的库将会有-p作为后缀。
-disable-asserts：不使用assert()调用
-enable-unixexamples：生成在Unix的用户态下运行OSKit的一些部件的支持代码和例子程序，目前支持FreeBSD和Linux。
-enable-doc：在编译时生成OSKit的文档。这样做除了要花费很多时间以外，还需要LaTex和dvips。已经生成的.ps和.html格式的文档在源码目录中。
在开始实际编译OSKit之前，可以做以下的一些事情忽略那些不需要的部分，使编译工作完成的更快一些：
修改<oskit/dev/linux_ethernet.h>，使其只包括需要的行。除了可以让编译速度更快以外，对于某些不兼容的硬件，也需要这样做，以防止死机。
修改<oskit/dev/linux_scsi.h>，使其只包括需要的驱动程序。
修改<oskit/fs/linux_filesystem.h>，使其只包含需要的文件系统。
修改源码根目录下的GNUmakefile，设定SUBDIRS，使其只有需要的目录。只有在对OSKit有了一些使用经验之后并且知道你需要哪些目录以后，才可以这样做。直接在GNUmakefile.in中指定subdirs也可以达到这样的目的，那样做的好处是防止以后再次进行配置时覆盖曾经做过的修改。
设定环境变量CFLAGS为-O1-pipe。这会让编译器在编译时所做的优化工作比较少，并且在编译器不把临时文件写到内存虚拟的文件系统时提高编译的速度。
1.5 OSKIT的编译
目前，编译OSKit需要以下的工具：
GNU make
GNU CC (gcc)2.95.2版。较新版本的gcc和egcs应当也可以使用，但没有测试过。
GNU binutils 2.8.x或2.9.1 with BFD2.9.1。
要编译OSKit，可以到源码的根目录（或者是用户指定的独立的目标目录）中运行GNUmake（在Linux系统上是make，在BSD系统上是gmake）。请注意OSKit需要GNUmake，不能用其它的make工具来代替它。为了防止混淆，OSKit的makefile都命名为GNUmakefile，而不是Makefile，这样的话，当用户错误地运行了其它的make工具时，它将报告找不到makefile的错误，而不是一些其它的错误。
要想只编译或重新编译OSKit的一部分代码（例如某个库），只需进入放置该部分的目标目录，然后在该目录中运行GNUmake。根目录中的GNUmakefile实际上不做任何事情，只是在其它各个目录中递归调用make命令。一些OSKit目录的编译需要其它的部分首先被编译，例如核心的例子在它们需要的OSKit库被编译之前是无法编译的。但OSKit的大部分库都可以在完全不需要其它库的情况下被编译。
当OSKit编译好以后，用户可以用"makeinstall"命令来安装它。缺省的情况下，这些库会被安装到/usr/local/lib中，而头文件会被安装到/usr/local/include中，除非用户在配置时使用了-prefix选项来指定目标目录。所有的OSKit头文件都安装在oskit/子目录中（例如/usr/local/include/oskit），这使它们不会和已经存在的任何头文件冲突。即使是OSKit库被安装在主库的目录中（如/usr/local/lib），所有的OSKit库文件都有前缀oskit_，这可避免与其它不相关的库相混淆。例如，OSKit的最小化C库命名为liboskit_c.a，而不是libc.a，这使用户可以在同样的目录中安装一个实际的C库。
标准的make变量如CFLAGS和LDFLAGS被OSKit的Build工具所使用，但是在OSKit的makefile中没有定义，它们可以在命令行上被使用。例如，你可以用命令"makeCFLAGS="-save-temps""来使GCC把它编译过程中产生的中间文件留在目标目录中（我们内部规定，OSKit的makefile中的变量都以OSKIT_作为前缀。）
1.6OSKIT的使用
要使用OSKit，可以在开发核心时使用OSKit提供的部件库、函数库，并在编译时将所使用的库链接到核心映象中。在OSKit的examples目录下有许多的例子核心，开发者可以通过查看以及运行这些核心来学习OSKit中各种库和映象Makefiels的编写方法。
OSKit中的库都进行了很好的设计，用户可以根据需要替换其中的任何一个库，由于在OSKit的文档中对每个库与其它库的依赖关系进行了详细的说明，因此用户可以很轻松的替换掉某个部件，而不会带来麻烦。实际上，在很多情况下，特别是在某些函数库中，为了有效的使用OSKit，是必须要替换掉其中的一些函数或者符号的。要重载某个库中的函数或者符号，只要在核心或应用程序中再定义一遍就可以了，链接程序会确保去使用所定义的函数和符号。OSKIT设计者强烈建议使用链接的方法去替换掉OSKit的某个部件，而不是直接修改OSKit的源码（除了修改源码中的Bug）。保持自己的核心和OSKit分开，会使升级到新版本的OSKit更加容易。
当完成核心的编写工作后，使用gcc中的－c选项把核心源码编译成一个或多个.o文件，然后创建Gnumakerules文件，把写好的.o文件与核心中使用的其它库文件按gcc的规范写入这个文件中。运行make，这些文件会被链接成一个核心。
启动核心有几种方法：当OSKit配置成在Linux或其它的使用ELF可执行文件结构的主机上使用时，就可以使用OSKIT提供的mklinuximage将核心制作成一个标准的可以从LILO或其它Linux引导程序引导的内核映象。当OSKit配置成在Mach或BSD系统上工作时，就可以使用OSKIT提供的mkbsdimage建立一个a.out格式的映象，这个映象可以从任何BSD或Mach的引导程序引导。需要注意的是mkbsdimage需要GNU ld能够正常的工作，在BSD系统上，通常都是不使用GNU的ld的，用户必须要自己手动编译并安装GNU的ld。当目标机以DOS为基础（如i386-msdos或i386-moss）时，就要使用mkdosimage。和mkbsdimage一样，mkdosimage也需要GNU的ld，必须要首先安装GNU的ld，并且将其配置成为可以交叉编译MS-DOS的文件，然后mkdosimage才能正常的工作。此外，OSKIT还提供了mkmbimage脚本，与其它的脚本不同，它不会做任何的转换，它只是允许将内核与其它的文件合成一个MultiBoot（有关Multiboot的问题，请见第五章）映象，这个映象可以和MultiBoot引导程序（如GRUB和NetBoot）一起使用。如果在你的系统上安装了Perl，就可以用一个同样功能的程序mkmb2来代替它，这个程序工作的更快一些。它的用处和mkmbimage是一样的。
当用OSKIT制作的核心启动时可以附加命令行参数，不同的引导程序可以将它们转化成自己的命令行格式，OSKIT对命令行参数规定了格式：
progname[<boot-opts and env-vars> -]<args tomain>
注意，如果没有"-"的话，所有的参数都将被传递给main函数。
缺省的OSKitMultiboot启动代码会把这些字符串转换成为C风格的argv/argc参数，环境变量数组，和记录在全局变量oskit_bootargv/osit_bootargc中的启动参数。
argv/argc和环境变量数组会传递给main程序，后者通常作为一个名为envp的第三参数。oskit_bootargv/oskit_bootargc中的引导参数会被缺省的OSKit控制台启动代码解释，并且下面的标志有着特殊的意义：
-h：使用串口作为控制台，参考-f标志。具体使用的串口由libkern中的base_console.c中的变量cons_com_port来控制。
-d：激活通过串口使用GDB，具体使用的串口由libkern中的base_console.c中的变量cons_com_port来控制。这个串口可以不同于控制台的串口，实际上最好是这样。
-p：激活剖析功能。操作系统的内核必须是编译成为支持剖析功能的。
-k：打开killswitch支持，这允许向第二个串口上传送字符以中止内核的运行。
-f：当使用一个串行的控制台时，使其工作在115200的速率而不是缺省的9600。这是Utah的扩展而并不在BSD之中。
这些参数都是以BSD为中心指定的，这是因为在犹它大学OSKIT的设计者通常都是用FreeBSD的引导程序引导内核。
此外，如果使用了NetBoot引导程序，在oskit_bootargv中还会有另一个参数：
-retaddraddress
这个参数指定一个OSKit可以跳到并且将控制权还给NetBoot的物理内存地址。Libkern中的bas_console.c中的缺省的_exit函数在退出时使用这个值。
1.7OSKit的执行环境
OSkit中的许多部件在核心和用户方式下都可以使用，这就需要对部件的执行环境作出定义，例如部件什么时候可以嵌套进入等。此外，OSKIT使用了许多其它操作系统的代码，例如设备驱动程序和网络协议栈，都是原封不动的从原有的核心如BSD和Linux中借用来的，OSKIT通过附加代码模拟原始执行环境使得这些执行模块比它们原始执行环境更简单，用户也不需要详细了解原执行环境的细节。下面对OSKIT的每种执行模块进行简单的介绍。
纯执行模块。这是OSKIT执行环境中最简单的模块。这些部件或函数中没有全局变量或静态变量，只使用和处理目标环境传递的数据。例如函数strlen，它只通过目标环境传递给它的字符串指针求出字符串的长度，并将其返回，它只接触参数数据域而不影响目标环境。当这些函数使用的数据集是分离的，它们可以安全地同时被调用，而不需要同步，反之则不行。例如对重叠的目标缓冲区并发使用memcpy调用是不安全的。
非纯执行模块。这些模块中使用了全局变量或有可能改变全局共享状态，例如liboskit_kern（核心支持库）中的许多函数建立和访问全局处理器寄存器和数据结构，因此它们是非纯执行模块。非纯执行模块有以下特点：
*非纯函数和部件可能依赖于全局状态，如全局变量、静态变量、处理器中特殊寄存器等。
*除非有明确的声明，非纯函数和部件是不可重入的，并且运用在多线程系统中也是不安全的。为了在一个多线程/多处理器环境中使用这些函数和部件，目标操作系统必须提供适当的同步代码。
阻塞模块。它扩展了非纯模块以支持非抢占的多线程，这些模块中有一类可重入的函数称为阻塞函数，在这模块中，除非明确声明为非阻塞函数，否则函数是阻塞的。为了在一个可抢占的、可中断的或者多处理器的环境中使用阻塞模块，必须在进入模块前加锁，在退出模块时将锁释放。
可中断阻塞模块。在它之中每个部件都是一个单线程的执行域，在一个给定的时刻，只有一个（虚拟的或者物理的）CPU可以执行部件中的代码。例如：在一个多处理器系统中，在进程级，任意时刻在一个部件集内只有一个CPU被允许执行；这能够通过在部件前后放置全局锁来实现。
此外，OSKit的执行环境还有以下特点：
在一段时间内，部件中可以存在多个活动进程，但在某时刻只有一个进程被执行。
目标操作系统给每个活动进程提供一个独立堆栈，这个堆栈在阻塞函数运行时被保留。只有在操作完成后，对部件的调用返回时才放弃该堆栈。
部件中的代码总是运行在两个级别中之一，进程级或中断级。有意思的是一些部件的函数和方法只能在进程级被调用，而另一些只能在中断级被调用，还有的能在任何级别被调用。调用的细节属于接口描述的一部分。
部件中无论进程级或中断级的操作都能被部件中的中断处理程序中断，除非代码调用osenv_intr_disable屏蔽了中断。
当部件在进程级运行时，OSKIT假定中断开放，部件在处理过程中可能临时屏蔽掉中断，但必须在返回到目标操作系统前重新激活。同样，当部件在中断级运行时，OSKIT假定中断被屏蔽，但是部件可以在目标操作系统允许其它中断级别的活动中断该部件时重新激活中断。
当目标操作系统在一个部件内中断一个进程级的活动时，在继续这个活动前，操作系统必须执行完这个中断级别的活动。同理，若一个中断级的活动被中断，那么最近的中断级别的活动必须在继续前一个中断级别的活动之前完成。
部件中运行在中断级别的代码不能调用目标操作系统提供的阻塞回调函数；只有非阻塞的回调函数能够在中断级别被调用。
OSKit的部件对象模型 第二章2000年12月3日21:33
作 者： 洪宁
导师：陈朔鹰
第二章 COM规范介绍
OSKit作为一套开发操作系统的工具，其最大的特色是在操作系统的整体设计中采用了COM的思想，将操作系统中各个不同功能的部分设计成独立的COM模块，使得操作系统的开发者能很方便地按照COM的规范开发出符合自己需要的功能模块，将OSKIT中的相应模块替换，但却能继续使用OSKIT中的其它模块。而且对每个COM模块内部的接口也可以进行改写，添加其未实现的功能，删除不必要的功能，最终实现真正满足自己要求的操作系统。这些OSKIT特性的实现无一不是有赖于COM的机制。因此，本章对COM中的基本概念和COM规范进行简单的介绍。
2.1 COM的基本概念
由于COM是由组件技术发展而来，因此在介绍COM机制之前有必要先对组件进行必要的说明，然后再对COM的基本概念进行说明。
2.1.1 组件技术
在计算机软件发展的早期，一个应用系统往往是一个单独的应用程序。应用越复杂，程序就越庞大，系统开发的难度也就越大。而且，一旦系统的某个版本完成后，在下个版本出来之前，应用程序不会再有所改变。而对于庞大的程序来讲，更新版本的周期很长，在两个版本之间，如果由于操作系统发生了变化，或者硬件平台有了变化，则应用系统就很难适应这种变化。所以这类单体应用程序已经不能满足计算机软硬件的发展需要。
从软件模型角度来考虑，一个很自然的想法就是把一个庞大的应用程序分成多个模块，每个模块保持一定的功能独立性，在协同工作时，通过相互之间的接口完成实际的任务。我们把每一个这样的模块称为组件，一个设计良好的应用系统往往被切分成一些组件，这些组件可以单独开发，单独编译，甚至单独调试和测试。当所有的组件开发完成后，把它们组合在一起就得到了完整的应用系统。当系统的软硬件环境发生变化或者用户的需求有所更改时，并不需要对所有的组件进行修改，而只需对受影响的组件进行修改，然后重新组合得到新的升级软件。这种组件化程序设计技术，不同于传统的结构化程序设计技术，也不同于现在被广泛采用的面向对象程序设计技术。可以说，组件化程序设计位于这两者之上，它更注重于系统的全局，要求从系统的全方位进行考察。
2.1.2 什么是COM
COM，即组件对象模型，是一种以组件为发布单元的对象模型，这种模型使各软件组件可以用一种统一的方式进行交互。COM既提供了组件之间进行交互的规范，也提供了实现交互的环境，因为组件对象之间交互的规范不依赖于任何特定的语言，所以COM也可以是不同语言协作开发的一种标准。COM不仅仅提供了组件之间的接口标准，它还引入了面向对象的思想。在COM规范中,把对象称为COM对象。组件模型为COM对象提供了活动的空间，COM对象以接口的方式提供服务，下图表明了COM组件、COM对象和COM接口三者之间的关系。
一个组件程序可以包含多个COM对象，而且每个COM对象可以实现多个接口。当另外的组件或普通程序（即组件的客户程序）调用组件的功能时，它首先创建一个COM对象或者通过该对象所实现的COM接口调用它所提供的服务。当所有的服务结束后，如果客户程序不再需要该COM对象，那么应该释放掉对象所占有的资源，包括对象自身。
2.1.3 COM结构
前面已经提到过，COM为组件和应用程序之间进行通信提供了统一的标准，它为组件程序提供了一个面向对象的活动环境。
COM标准包括规范和实现两大部分，规范部分定义了组件和组件之间通信的机制，这些规范不依赖于任何特定的语言和操作系统，只要按照该规范，任何语言都可以使用。在这里主要讨论COM规范，至于其在OSKIT中的实现，在后面的章节中讨论。
COM主要是由对象和接口两部分组成。对象是某个类(class)的一个实例；而类则是一组相关的数据和功能组合在一起的一个定义。使用对象的应用（或另一个对象）称为客户，有时也称为对象的客户。接口是一组逻辑上相关的函数集合，其函数称为接口成员函数。按照习惯，接口名常以"I"为前缀，例如"IUNKNOWN".对象通过接口和成员函数为客户提供各种形式的服务。
2.1.4客户/服务器模型
可以很容易看出，对象和客户之间的相互作用是建立在客户/服务期模型基础上的，客户/服务器模型的一个很大的优点是稳定性好，而稳定性正是COM模型的目标，尤其对于跨进程的程序通信，稳定性更会带来性能上的高可靠性。
客户/服务器模型是一种发展比较成功的软件模型，因为这种模型有以下一些优势：
稳定性好、可靠性高。客户/服务器模型简化了应用，把任务进行分离，客户和服务器各司其职，共同完成任务。
软件的可扩展性好。一个服务器进程可以为多个客户提供服务，客户也可以连接到不同的服务器上，这种模型的连接非常灵活。
可以很容易看出，对象和客户之间的相互作用是建立在客户/服务器模型的基础上的，客户/服务器模型的一个很大优点是稳定性好，而稳定性正是COM模型的目标，尤其对于跨进程的程序通信，稳定性更会带来性能上的高可靠性。
然而，COM不仅仅是一种简单的客户/服务器模型，有时客户也可以反过来提供服务，或者服务方本身也需要其他对象的一些功能，在这些情况下，一个对象可能既是服务器也是客户。COM能够有效地处理这种情况。
2.2 COM对象
在COM规范中，并没有对COM对象进行严格的定义，但COM提供的是面向对象的组件模型，COM组件提供给客户的是以对象形式封装起来的实体。客户程序与COM组件程序进行交互的实体是COM对象，它并不关心组件模块的名称和位置（即位置透明性），但它必须知道自己在与那个COM对象进行交互。
类似于C++语言中类（class)的概念，COM对象也包括属性（也包括状态）和方法（也称为操作），对象的状态反映了对象的存在，也是区别于其他对象的要素；而对象所提供的方法就是对象提供给外界的接口，客户必须通过接口才能获得对象的服务。对于COM对象来说，接口是它与外界交互的唯一途径，因此，封装特性是COM对象的基本特征。
COM对象可以由多种语言来实现，例如C++,JAVA,C(正如在OSKIT中)。如果用C++来实现COM对象，则很自然可以用类（class)来定义COM对象，类的每个实例代表一个COM对象，类的数据成员可用于反映对象的属性，而接口自然可以定义成类的成员函数。但在非面向对象语言，例如C语言中，对象的概念可能变成一个逻辑概念，如果两个对象同时存在，则在接口实现中必须明确知道所进行的操作是针对哪个对象的，这个过程可由COM接口的定义来保证。
2.2.1 COM对象的标识－CLSID
前面已经说过，COM组件的位置对客户来说是透明的，因为客户并不直接去访问COM组件，客户程序通过一个全局标识符进行对象的创建和初始化工作。如果从标识符的可读性来考虑，使用字符串是最简单的方法，但这样做会增加名字冲突的可能性，这样组件的唯一性就很难保证，所以不能采用这种方法。而如果按照TCP/IP网络协议标识计算机采用的IP地址标识方法，那么每个组件对象都应该分配一个整数，该整数唯一标识了组件对象。问题在于，为了保证唯一性，必须有一个专门的权威机构为COM组件分配整数标识符，对于COM组件的开发和使用，显然不能满足实际需要。
使用定长位数的整数来标识组件对象是合理的，为了在没有中心机构管理的情况下保证唯一性，COM规范采用了128位全局唯一标识符GUID，这是一个随机数，并不需要专门机构进行分配和管理。因为GUID是随机数，所以并不绝对保证唯一性，但发生标识符相重的可能性非常小。从理论上讲，如果一台机器每秒产生10000 000个GUID，则可以保证（概率意义上），3240年不重复。
下面是一个GUID的例子：
{54BF6567--1007--11D1--B0AA--444553540000}。
在C/C++语言中可以用这样的结构来描述：
typedefstruct_GUID
{
DWORDData1;
WORD Data2;
WORD Data3;
Byte Data4[8];
}GUID;
于是前面的GUID例子可以定义为
extern "c" const GUID CLSID_MYCLASID =
{0x54bf6567,0x1007,0x11d1,{0xb0,0xaa,0x44,0x45,0x53,0x54,0x00,0x00}};
CLSID是用来标识COM对象的GUID，因此，CLSID在结构定义上GUID一致。GUID并不是专门用来定义COM对象标识符的，它也用于定义其它实体的标识符，比如接口标识符。
2.3 COM接口
因为COM对象的客户与对象的服务之间通过接口进行交互，所以组件之间接口的定义至关重要。COM规范的核心内容是关于接口的定义。
2.3.1 接口的定义和标识
从技术上讲，接口是包含了一组函数的数据结构，通过这组数据结构，客户代码可以调用组件对象的功能。接口定义了一组成员函数，这组成员函数是组件对象暴露出来的所有信息，客户程序利用这些函数获得组件对象的服务。
客户程序用一个指向接口数据结构的指针来调用接口成员函数。如图所示，接口指针实际上又指向另一个指针，这第二个指针指向一组函数，称为接口函数表，接口函数表中每一项为4个字节长的函数指针，每个函数指针与对象的具体实现连接起来。通过这种方式，客户只要获得了接口指针，就可以调用到对象的实际功能。
通常，接口函数表被称为虚函数表（virtual functiontable，简称vtable），在OSKIT中称为函数动态派遣表。对于一个接口来说，它的虚函数表是确定的，因此接口的成员函数个数是不变的，而且成员函数的先后顺序也是不变的；对于每个成员函数来说，其参数和返回值也是确定的。在一个接口的定义中，所有这些信息都必须在二进制一级确定，不管什么语言，只要能支持这样的内存结构描述，就可以定义接口。此外，成员函数除了参数类型是确定的，还要使用同样的调用习惯。客户程序在调用成员函数之前，必须先把参数压入栈中，然后再进入成员函数中，成员函数依次把参数从栈中取出来，在函数返回之前或返回后，必须恢复栈的当前位置，才能保证函数正常运行。由于OSKIT是用C语言来实现的，因此客户程序只需要包含接口声明的头文件，就可以调用COM对象的接口，而组件程序必须提供具体的实现过程，也就是说，如果一个COM对象实现了这个接口，则它提供的接口指针所指向的结构中，每个成员必须是有效的函数指针。
因为接口被用于组件程序和客户程序的通信桥梁，所以接口应该具有不变性，一个COM对象可以支持多个接口。为了让客户程序标识每个接口，类似于COM对象的标识方法，COM接口也使用全局唯一标识符，它被称为接口标识符（IID，interfaceidentifier）。
例如：
extern "c" const IID IID_Iunknown =
{ 0x00000000,0x0000,0x0000, {0xc0,0x00,0x00,0x00, 0x00, 0x00, 0x00,0x46} };
如果客户程序要使用一个COM对象的某个接口，则它必须知道该接口的IID和接口所能提供的方法（即接口成员函数）。
2.3.2 接口的一些特点
*二进制特性
接口规范并不建立在任何编程语言的基础上，而是规定了二进制一级的标准。任何语言只要有足够的数据表达能力，它就可以对接口进行描述，从而可以用于与组件程序有关的开发。
*接口不变性
接口是组件客户程序和组件对象之间的桥梁，接口如果经常发生变化，则客户程序和组件程序也要跟着变化，这对于系统的开发非常不利，也不符合组件化程序设计的思想。因此，接口应该保持不变，只要客户程序和组件程序都按照既定的接口设计进行开发，则可以保证在两者独立开发结束后，它们的协作运行能力能达到预期的效果。
*继承性
COM接口具有不变性，但接口也需要发展。类似与C++中的继承性，接口也可以继承发展。与C++中的继承不同，接口继承只是说明继承，即派生的接口只继承了基接口的成员函数说明，并没有继承基接口的实现，因为接口定义不包括函数实现部分，而且接口继承只允许单继承，不允许多重继承。根据COM规范，所有的接口都必须从Iunknown接口派生，而且一般的接口都是直接派生于Iunknown接口。
*多态性－运行过程中的多态性
多态性是面向对象系统的重要特征，COM对象也具有多态性，其多态性通过COM接口体现。多态性时客户程序可以用统一的方法处理不同的对象，甚至是不同类型的对象，只要它们实现了同样的接口。如果几个不同的COM对象实现了同一个接口，则客户程序可以用同样的代码调用这些COM对象。因为COM规范允许一个对象实现多个接口，因此，COM对象的多态性可以在每个接口上得到体现。
2.4 Iunknown接口
COM规范说明，COM定义的每一个接口都必须从Iunknown继承过来，其原因在于Iunknown接口提供了两个非常重要的特征：生存期控制和接口查询。客户程序只能通过接口与COM对象进行通信，需要控制对象的存在与否。如果客户还要继续对对象进行操作，则它必须保证对象能一直存在于内存中；如果客户对对象的操作已经完成，而且不再需要该对象，则它必须及时地把对象释放掉，以提高资源的利用率。Iunknown引入了"引用计数"（referencecounting）方法，可以有效地控制对象的生存周期。
另一方面，如果一个COM对象实现了多个COM接口，在初始时刻，客户程序不大可能得到该对象所有的接口指针，它只会拥有一个接口指针。Iunknown使用了"接口查询"（QueryInterface）的方法来完成接口之间的跳转。
Iunknown包含了三个成员函数：QueryInterface、Addref和Release。函数QueryInterface用于查询COM对象的其它接口指针，函数Addref和Release用于对引用计数进行操作。
2.4.1 引用计数
COM采用了"引用计数"技术来解决内存管理的问题，COM对象通过引用计数来决定是否继续生存下去，对于一个COM对象来说，只要有任一个逻辑模块还需要使用它，那么它就必须驻留在内存中，不能释放自己。因此，每一个COM对象都记录了一个称为"引用计数"的数值，该数值的含义是有多少个有效指针在引用该COM对象。当客户得到了一个指向该对象的接口指针时，引用计数增1；当客户用完了该接口指针后，引用计数减1。当引用计数减到0时，COM对象就应该把它自己从内存中清除掉。当客户程序对一个接口指针进行了复制，则引用计数也应该相应增加。Iunknown的接口成员函数Addref和Release分别完成引用计数的加1和减1操作。通过引用计数，COM对象的客户程序可以通过接口指针很好地控制对象的生存期。
2.4.2 实现引用计数
按照COM规范，一个COM组件可以实现多个COM对象，而且每个COM对象又可以支持多个COM接口。因此可以实现在COM组件一级，COM对象一级，甚至于对象的每个接口一级设置引用计数。
如果在组件一级设置引用计数，那么可以控制组件模块的生存周期，但不能控制COM对象的生存周期。如果一个组件有两个COM对象，则必须等到所有的COM对象都使用完以后，所有的COM对象才可以一起被释放。这样做降低了系统资源的利用率。
如果在接口一级设置引用计数，可以跟踪客户对象COM对象的使用情况。对于实现多个接口的对象，很有可能某些接口没有被客户使用，那么这些接口相关的资源可以不被占用。但每当一个接口的引用计数减到0时，它必须给对象发出通知，对象在接到通知后，需要判断是否所有的接口引用计数为0，若是，就把自己释放，然后再进一步通知组件程序，组件程序接到通知后判断是否所有的对象都已被清除，若是，则它可以被卸出内存。这个过程比较繁琐，而且也需要占用一部分的时间。
从折中的角度出发，比较合理的方案是采用对象一级的引用计数以便控制对象和组件的生存周期。这样使多个对象的组件程序可以有效地提高系统资源利用率。当一个对象被释放掉以后，它必须通知组件程序，如果组件程序发现已经没有对象存在了，则组件模块应该可以从内存中卸出。因此，组件程序应该保持一份有效对象的记录，可以用一个全局的对象计数值来控制组件的生存周期。
2.4.3 接口查询
按照COM规范，一个COM对象可以实现多个接口，客户程序可以在运行时刻对COM对象的接口进行询问，只有对象实现了该接口，对象才能提供这样的接口的服务。要实现接口查询，就要使用Iunknown的成员函数QueryInterface。
QueryInterface函数的IDL（interface description language，接口描述语言）语言说明：
HRESULT QueryInterface([in] REFIID iid,[out] void **ppv);
函数的输入参数iid为接口标识符IID，它是与GUID一样的128位整数，用来标识一个COM对象所支持的接口。输出参数ptv为查询得到的结果接口指针，如果对象没有实现iid所标识的接口，则输出参数ptv指向空（NULL）。当客户创建了COM对象后，创建函数总会返回一个接口指针，因为所有的接口都继承于Iunknown，所以，所有的接口都有QueryInterface成员函数，于是，在得到了初始的接口指针之后，可以通过它的QueryInterface函数获得该对象支持的任何一个接口指针。
2.4.4 COM对象的接口原则
COM规范对接口的查询给出了以下一些规则：
*对于同一个对象的不同接口指针，查询得到的IUnknown接口必须完全相同。也就是说，每个对象的Iunknown接口指针是唯一的，因此，对两个接口指针，可以通过判断其查询到的Iunknown接口是否相等来判断它们是否指向同一个对象。
*接口对称性。对一个接口查询其自身总应该成功。
*接口自反性。如果从一个接口指针查询到另一个接口指针，则从第二个接口指针再查询第一个接口指针必定成功。
*接口传递性。如果从第一个接口指针查询到第二个接口指针，从第二个接口指针可以查询到第三个接口指针，则从第三个接口指针可以查询到第一个接口指针。
*时间无关性。如果一个接口在某一个时刻可以查询到另一个接口指针，则以后任何时候再查询相同的接口指针，一定可以查询成功。
2.5 COM特性
COM规范所定义的组件模型，除了前面提到的面向对象的特性和客户/服务器特性这两个基本特性外，值得重点说明的就是COM规范的语言无关性，对进程的透明性和它的可重用机制。
2.5.1语言无关性
COM对象的定义不依赖于特定的语言，因此，编写组件对象所使用的语言与编写客户程序的语言可以有所不同，只要它们都能生成符合COM规范的可执行代码即可。COM标准与面相对象的编程语言不同，它所采用的是一种二进制代码级的标准，而不是源代码级的标准。因此，COM的语言无关性实际上为跨语言合作开发提供了统一标准。在OSKIT中，所有的COM对象都是用C语言写成的，但只要依据COM规范，完全可以用C++改写其中的某些模块，然后单独编译该模块，而可以继续使用OSKIT中其它的原有模块。
2.5.2 进程透明特性
COM所提供的服务组件对象在实现时有两种进程模型，进程内对象和进程外对象。如果是进程内对象，则它在客户进程空间运行；如果是进程外对象，则它运行在同一机器上的另一个进程空间，或者在远程机器的进程空间中。虽然COM对象有不同的进程模型，但这种区别对于客户机来说是透明的，因此客户程序在使用组件对象时可以不管这种区别的存在，只要遵循COM规范即可。然而，在实现COM对象时，还是应该慎重选择进程模型。进程内模型的优点是效率高，但组件不稳定会引起客户进程崩溃，因此组件进程可能会危及客户；进程外模型的优点是稳定性好，组件进程不会危及客户程序，一个组件进程可以为多个客户程序提供服务，但进程外组件开销大，而且调用效率相对低一些。
实现这种进程透明性的关键在于COM库，COM库负责组件程序的定位，管理组件对象的创建和对象与客户之间的通信。当客户创建组件对象时，COM库负责装入组件模块或者启动组件进程。因此，客户程序可以不管组件对象的进程模型，即使组件的进程模型发生了变化，客户程序也不需要重新编译。
2.5.3 可重用性
可重用性是任何对象模型的实现目标，尤其是大型系统，可重用性非常重要。而且，由于COM标准是建立在二进制代码级的，因此COM对象的可重用性与一般的面向对象语言有所不同。
对于COM对象的客户程序来说，它只是通过接口使用对象提供的服务，它并不知道对象内部的实现过程，因此，组件对象的重用性建立在组件对象的行为方式上，而不是具体的实现上，这是重用的关键。
COM用两种方式实现对象的重用。假定有两个COM对象，对象1希望能重用对象2的功能，对象1称为外部对象，对象2称为内部对象。
包容方式。对象1包含了对象2，当对象1需要用到对象2的功能时，它可以简单地把实现交给对象2来完成，虽然对象1和对象2实现同样的接口，但对象1在实现接口时实际上调用了对象2的实现。
聚合方式。对象1只需简单地把对象2的接口递交给客户即可，对象1并没有实现对象2的接口，但它把对象2的接口也暴露给客户程序，而客户程序并不知道内部对象2的存在。
对象重用是COM规范很重要的一个方面，它保证COM可用于构造大型的软件系统，而且，它使复杂系统简化为一些简单的对象模块，体现了面向对象的思想。
OSKit的部件对象模型 第三章2000年12月3日22:07
作 者： 洪宁
导师：陈朔鹰
第三章 OSKIT中COM机制的实现
3.1 OSKIT中COM的基本定义
在OSKIT中有关COM的基本定义在com.h中，在该文件中定义了OSKIT中的iid，COM的调用规范，以及OSKIT中的Iunknown接口。
OSKIT中GUID的定义如下：
struct oskit_guid{
oskit_u32_t data1;
oskit_u16_t data2;
oskit_u16_t data3;
oskit_u8_tdata4[8];
};
其中oskit_u32_t、oskit_u16_t、oskit_u8_t分别是32位、16位、8位无符号整形。OSKIT使用这样的定义而不使用例如win32中的DWORD有两方面的原因：首先，这样定义使OSKIT保持一致的风格，向开发人员呈现出一致的命名规则。其次，如果oskit在win32或相似的环境中使用，能避免与实际的WIN32头文件冲突。
OSKIT中的调用规范如下：
#define OSKIT_COMCALL OSKIT_STDCALL
#defineOSKIT_COMDECL oskit_error_t OSKIT_COMCALL
#defineOSKIT_COMDECL_U oskit_u32_t OSKIT_COMCALL
#defineOSKIT_COMDECL_V voidOSKIT_COMCALL
其中，OSKIT_STDCALL是在compile.h中定义的有关编译器设置的宏，这个宏在OSKIT安装前的configure步骤中被赋值（configure步骤请见第一章）。OSKIT这样定义调用规范，是为了用不同的编译器都可以编译OSKIT，而不必在编写程序时考虑这些调用的细节。而OSKIT_COMDECL就是带错误返回码的调用，OSKIT_COMDECL_U是返回值为32位无符号整型的调用，OSKIT_COMDECL_V是不带返回值的调用。
OSKIT中Iunknown接口的定义如下：
struct oskit_iunknown
{
structoskit_iunknown_ops *ops;
};
typedef struct oskit_iunknownoskit_iunknown_t;
struct oskit_iunknown_ops
{ / *查询对象是否支持某个特定的接口，若支持则返回该接口的指针*/
OSKIT_COMDECL (*query)(oskit_iunknown_t*obj,
const oskit_iid_t *iid, void **out_ihandle);
/*增加某个接口的引用计数*/
OSKIT_COMDECL_U (*addref)(oskit_iunknown_t *obj);
/*将对某个接口或对象的引用计数减1，若引用计数为0，则释放该接口或对象 */
OSKIT_COMDECL_U(*release)(oskit_iunknown_t*obj);
};
其中，query的参数中obj是要查询的COM对象，iid是要查询的接口的全局标识符，若查询成功，out_ihandle返回指向被查询接口的指针，若查询失败，则返回空指针。
上面可以看到，oskit_iunknown结构中存放着指向函数表格的指针，称为ops，而函数表格是通过一个称为oskit_iunknown_ops的结构实现的，这个结构中定义了指向该接口所实现的所有成员函数的指针。只要对该结构进行赋值，就可以通过这个结构调用该接口的所有成员函数。
由于Iunknown接口是由各个COM对象自己实现的，因此在COM.H中没有对该结构进行赋值，后面章节中将会详细剖析OSKIT中一个COM对象的实例，那时再对该结构的赋值进行讨论。
COM.H还通过宏定义对Iunknown接口的成员函数进行了包装，如下所示：
#define oskit_iunknown_query(obj, iid, out_ihandle)\
((obj)->ops->query((oskit_iunknown_t *)(obj),(iid),
(out_ihandle)))
#define oskit_iunknown_addref(obj)\
((obj)->ops->addref((oskit_iunknown_t *)(obj)))
#defineoskit_iunknown_release(obj) \
((obj)->ops->release((oskit_iunknown_t*)(obj)))
这使开发人员可以对它们的调用更加方便。此外，顺便提一句，OSKIT的一大特色就是对宏定义的灵活使用。在这方面值得大家借鉴。
3.2 实例分析Iunknown接口的实现
OSKIT中并不是每个接口都允许被引用多次，比如内存接口，当系统初始化时便对定义好的静态内存结构进行赋值，然后所有对内存的操作都依赖于该内存接口，也就是说，在该内存接口中不存在实现Iunknown接口的问题。但也有可以存在可以引用多次的接口，如流接口（stream），C环境接口（OSKIT为核心提供了一个最小的C库，开发这也可以使用自己定义的C库加以替换）。本节就以C环境接口为例分析OSKIT中Iunknown接口的实现。
3.2.1 C环境对象的结构
OSKIT中C环境对象的结构如下：
struct genv {
oskit_libcenv_t libcenvi; /* C环境接口*/
int count; /* 引用计数*/
oskit_fsnamespace_t *fsn;
charhostname[256];
oskit_ttystream_t *console;
void(*exit)(int);
void (*siginit)(int (*func)(int, int, void*));
#ifndefPTHREADS
oskit_timer_t *sleep_timer;
oskit_osenv_sleep_t *sleep_iface;
osenv_sleeprec_t*sleeprec;
#endif
};
3.2.2 C环境接口及其对Iunknown接口的实现
C环境接口是在libcenv.h中定义的，为了让大家对OSKIT中COM接口有一个完整的认识，现将整个接口的说明列出:
struct oskit_libcenv {
struct oskit_libcenv_ops *ops; /* 指向函数表格的指针*/
};
typedef struct oskit_libcenv oskit_libcenv_t;
下面是函数表格：
struct oskit_libcenv_ops {
/* 对Iunknown接口的继承*/
OSKIT_COMDECL_IUNKNOWN(oskit_libcenv_t)
/* 获得及设置根文件系统*/
OSKIT_COMDECL (*getfsnamespace)(oskit_libcenv_t*s,
oskit_fsnamespace_t **out_dir);
OSKIT_COMDECL(*setfsnamespace)(oskit_libcenv_t *s,
oskit_fsnamespace_t *dir);
/*设置及获得主机名 */
OSKIT_COMDECL (*gethostname)(oskit_libcenv_t *s,
char*hostname, int len);
OSKIT_COMDECL (*sethostname)(oskit_libcenv_t*s,
const char *hostname, int len);
/* 调用及设置退出函数 */
OSKIT_COMDECL_V(*exit)(oskit_libcenv_t *s,
oskit_u32_t exitval);
OSKIT_COMDECL(*setexit)(oskit_libcenv_t *s,
void (*exitfunc)(int));
/* 设置及获得终端对象*/
OSKIT_COMDECL (*getconsole)(oskit_libcenv_t *s,
oskit_ttystream_t**out_ttystream);
OSKIT_COMDECL (*setconsole)(oskit_libcenv_t*s,
oskit_ttystream_t *ttystream);
/* 初始化信号库 */
OSKIT_COMDECL(*signals_init)(oskit_libcenv_t *s,
int (*func)(int, int, void*));
OSKIT_COMDECL (*setsiginit)(oskit_libcenv_t *s,
void(*sigfunc)(int (*func)(int,int,void *)));
/* 睡眠/唤醒接口 */
OSKIT_COMDECL_V(*sleep_init)(oskit_libcenv_t *s,
osenv_sleeprec_t*sleeprec);
OSKIT_COMDECL_U (*sleep)(oskit_libcenv_t *s,
osenv_sleeprec_t*sleeprec,
struct oskit_timespec *timeout);
OSKIT_COMDECL_V(*wakeup)(oskit_libcenv_t *s,
osenv_sleeprec_t *sleeprec);
/* 克隆整个对象*/
OSKIT_COMDECL (*clone)(oskit_libcenv_t *s,
oskit_libcenv_t**intf);
};
下面是定义C环境接口的iid
extern const struct oskit_guidoskit_libcenv_iid;
#define OSKIT_LIBCENV_IID OSKIT_GUID(0x4aa7dfe9, 0x7c74,0x11cf, 0xb5, 0x00, 0x08, 0x00, 0x09, 0x53, 0xad, 0xc2)
下面是对C库接口成员函数的包装，因为长度缘故，只写出部分：
#define oskit_libcenv_query(s, iid,out_ihandle) \
((s)->ops->query((oskit_libcenv_t *)(s), (iid),(out_ihandle)))
#define oskit_libcenv_addref(s)\
((s)->ops->addref((oskit_libcenv_t *)(s)))
#defineoskit_libcenv_release(s) \
((s)->ops->release((oskit_libcenv_t *)(s)))
下面是C库接口的实现：
static struct genv default_libcenv;
/* 定义静态的C环境对象 */
在OSKIT中，经常在初始化时大量使用静态定义，因为这样定义出来的结构在编译时就分配好了空间，使系统在启动时就可以使用这些结构，而不需要等到内存对象初始化完之后再动态分配空间。
Query 成员函数的流程图见下一页：
下面是Query成员函数的实现：
staticOSKIT_COMDECL
libcenv_query(oskit_libcenv_t *s, const oskit_iid_t *iid,
void **out_ihandle)
{
struct genv *g = (struct genv *) s;
/*将指向C库环境接口的指针转化为指向C库环境对象的指 */
if (memcmp(iid, oskit_iunknown_iid,sizeof(*iid)) == 0 ||
memcmp(iid, oskit_libcenv_iid, sizeof(*iid))== 0)
/* 通过比较要查询的iid和iunknown接口的iid以及c库环境接口的iid
相比较，如果相等，则表明该C库环境对象支持该接口*/
{ *out_ihandle = g->libcenvi;/*返回指向C环境接口的指针*/
g->count++; /*将引用计数加1*/
return 0;
}
*out_ihandle = 0;
return OSKIT_E_NOINTERFACE; /* 如果找不到，则返回出错信息*/
};
/* 增加引用计数 */
static OSKIT_COMDECL_Ulibcenv_addref(oskit_libcenv_t *s)
{ /* 将C库环境的接口指针转化为C库环境对象指针 */
structgenv *g = (struct genv *) s;
assert(g->count);
return++g->count; /*增加引用计数*/
}
Release 函数的流程见下一页：
/* 释放引用计数*/
libcenv_release(oskit_libcenv_t *s)
{ /* 将C库环境接口指针转化为C库环境对象指针*/
struct genv g = (struct genv ) s;
assert(g->count);
/*以下语句先将对象的引用计数减1，然后判断计数是否为0，若是则释
放对与其相关的接口的引用*/
if (--g->count == 0){
if (g->fsn) oskit_fsnamespace_release(g->fsn);
if(g->console) oskit_ttystream_release(g->console);
#ifndefPTHREADS
if(g->sleep_timer)
oskit_timer_release(g->sleep_timer);
if(g->sleep_iface)
oskit_osenv_sleep_release(g->sleep_iface);
#endif
sfree(g,sizeof(g));
}
return g->count; /*返回该对象的引用计数*/
}
现在对上面Iunknown接口的三个成员函数的实现思路作一定的解释。在OSKIT中，客户所能使用的只是对象提供给用户的接口指针，当用户在该接口中调用Query方法时，例如libcenv_query，并对该对象中的某个接口进行查询，这时，由于对象是否实现所查询接口是在对象结构中定义的，因此首先把接口指针进行强制类型转换，变为指向接口所属对象的指针，然后再将所要查询的接口iid与对象所实现的所有接口的iid逐一比较，如果与其中某一个接口的iid相等，则返回指向该接口的指针，如果无一相等，则返回错误信息。当用户使用addref方法时，同样也是先进行类型转换，然后将这个对象中的引用计数加1，若用户调用release方法，在进行类型转换后，将对象的引用计数减1，如果发现引用计数位0，则将释放整个对象的内存空间。
OSKit的部件对象模型 第四章2000年12月3日22:49
作 者： 洪宁
导师：陈朔鹰
第四章 OSKIT中的接口注册机制
4.1 概述
为了管理OSKIT中的接口，OSKIT系统引入了接口注册的机制。所谓接口注册，就是在系统中建立一个服务数据库，里面记载了所有在该数据库中注册的接口信息，包括对象名、接口的iid、对象的引用计数等。系统提供给用户一个指向服务接口的指针，通过该指针，用户可以实现创建自己的数据库，在某个数据库中注册接口，在数据库中注销先前注册的某个接口，获得用某个iid注册的第一个接口，获得用某个iid注册的所有接口。系统在初始化时自动创建了一个特殊的数据库，称为全局数据库，在该数据库中注册了许多对于系统来说十分关键的接口，例如C库环境接口，内存接口，并提供了一些其它的函数以方便对全局数据库的操作，如直接将接口注册入全局数据库，以及直接在全局数据库中进行接口查询等。通过这些函数，系统能快捷方便地管理全局数据库。
4.2 数据库对象
OSKIT中的数据库对象是在service.c中定有的，其定义如下：
struct db {
oskit_services_t servi; /* 服务接口 */
int count; /*引用计数 */
struct iidnode *iids; /* iid链指针 */
oskit_mem_t *memi; /*所要使用的内存对象指针*/
};
其中用到的iidnode结构如下：
struct iidnode {
struct iidnode *next;/*下一个iid节点*/
oskit_guid_t iid; /*全局iid*/
struct objnode *objs;/*对象节点指针*/
int objconut /*对象引用计数*/
};
而objnode的定义如下：
struct objnode {
struct objnode *next;/*下一个objnode节点*/
oskit_iunknown_t *intf; /*iunknown接口类型指针*/
};
由此，可以得出该数据库的结构图为：
4.3 服务接口的定义
服务接口定义如下：
struct oskit_services {
struct oskit_services_ops *ops;/*指向函数表格的指针*/
};
typedef struct oskit_services oskit_services_t;
structoskit_services_ops {
/*接口查询*/
OSKIT_COMDECL (*query)(oskit_services_t*s,
const struct oskit_guid *iid,void**out_ihandle);
/*增添引用计数*/
OSKIT_COMDECL_U (*addref)(oskit_services_t*s);
/*释放引用计数*/
OSKIT_COMDECL_U (*release)(oskit_services_t*s)
/*在数据库中注册接口*/
OSKIT_COMDECL (*addservice)(oskit_services_t*s,
const struct oskit_guid *iid, void*intf);
/*在数据库中撤销先前注册接口*/
OSKIT_COMDECL (*remservice)(oskit_services_t*s,
const struct oskit_guid *iid, void*intf);
/*在数据库中查询以某个iid注册的所有接口*/
OSKIT_COMDECL (*lookup)(oskit_services_t*s,
constoskit_guid_t *iid,void***out_interface_array);
/*在数据库中查询以某个iid注册的第一个接口*/
OSKIT_COMDECL(*lookup_first)(oskit_services_t *s,
const oskit_guid_t *iid, void**out_intf);
/*克隆整个数据库*/
OSKIT_COMDECL(*clone)(oskit_services_t*s,
oskit_services_t **intf);
};
另外在OSKIT中，还为操作全局数据库提供了一些函数，它们的定义如下；
/*创建全局数据库*/
oskit_error_toskit_global_registry_create
(structoskit_mem*memobject);
/*获得全局数据库*/
oskit_services_t*oskit_get_services(void);
/*在全局数据库中注册接口*/
oskit_error_toskit_register(const struct oskit_guid*iid,
void*interface);
/*在全局数据库中撤销先前注册的接口*/
oskit_error_toskit_unregister(const struct oskit_guid
*iid,void*interface);
/*查询用某个iid注册的所有接口*/
oskit_error_toskit_lookup(const oskit_guid_t *iid, void
***out_interface_array);
/*查询用某个iid注册的第一个接口*/
oskit_error_toskit_lookup_first(const oskit_guid_t *iid,
void**out_interface);
4.4 数据库服务接口的实现
4.4.1 创建数据库
OSKIT中创建数据库的实现思路是：使用某个内存对象分配出数据库对象所需的存储空间，然后创建数据库，给数据库对象的每个成员赋值，最后返回数据库的服务接口指针。其流程图见下一页：
其实现的源代码如下：
oskit_error_t oskit_services_create
(oskit_mem_t *memi, oskit_services_t**out_intf)
{ struct db *s;/*定义数据库对象*/
/*如果没有提供内存对象，则在全局数据库中查找*/
if (!memi){
/*在全局数据库中查找第一个内存对象*/
oskit_lookup_first(oskit_mem_iid,(void*) memi);
if (!memi)
panic("oskit_services_create:Nullmemory object!");
}
/* 给数据库对象分配内存空间 */
s =oskit_mem_alloc(memi, sizeof(*s), 0);
if (s == NULL)
returnOSKIT_E_OUTOFMEMORY;
s->count = 1; /*给引用计数赋值*/
s->memi =memi; /*给内存对象指针赋值*/
/*给数据库对象中的服务接口指针赋值*/
s->servi.ops =services_ops;
s->iids =0;
oskit_mem_addref(memi);
/* 在全局数据库中增加该内存对象的引用计数*/
*out_intf = s->servi; /*返回服务接口指针*/
return 0;
}
4.4.2 在数据库中注册接口
OSKIT在数据库中注册接口的过程是这样的，首先将服务接口指针转换为数据库对象指针，然后根据要注册的接口的iid，在数据库中查找已经注册的iid，若该iid已注册，则在该iid下查找用这个iid注册的接口名，如果找到则返回，否则，生成一个新的obj节点，并将要注册的接口赋给obj节点中的接口指针。如果要注册的iid找不到，则生成一个新的iid节点，在该iid节点下新建一个obj节点，并对它们进行赋值。在程序执行过程中，如果在分配内存时发现内存不够，则返回一个内存不足错误，由调用程序来处理。下面是注册接口的程序流程：
下面是注册接口的源程序：
参数：si:数据库指针
iid:需要进行注册的全局iid指针
interface:需要进行注册的接口指针
OSKIT_COMDECLservices_addservice(oskit_services_t *si,
const struct oskit_guid *iid,void *interface)
{ /*将服务接口指针转换为数据库指针*/
struct db *s = (struct db *) si;
/*将需要注册的接口指针转换为iunknown接口的指*/
oskit_iunknown_t *iu =(oskit_iunknown_t*)interface;
struct iidnode *in;/*定义iid节点指针*/
struct objnode *on, **onp; /*定义obj节点指针*/
/*查找或创建相应的iid节点 */
for (in = s->iids; ; in = in->next) {
if (in== NULL) {
/*如果没有找到，则创建新的iid节点*/
in =oskit_mem_alloc(s->memi, sizeof(*in), 0);
if (in == NULL)/*分配内存失败*/
return OSKIT_E_OUTOFMEMORY;/*返回内存不足错误*/
in->iid = *iid;
in->objs =NULL;
in->objcount = 0;
in->next =s->iids;/*在iid链中插入该iid节点*/
s->iids =in;
break;
}
if (memcmp(in->iid, iid,sizeof(*iid)) == 0)
break; /*找到了该iid节点，退出循环*/
}
/*在该iid的obj链中查找要注册的接口*/
for (onp = in->objs; *onp; onp =(*onp)->next) {
if ((*onp)->intf == interface)
return 0; /*找到后，直接返回*/
}
/* 为这个接口创建一个新的obj节点*/
�