操作系统实验报告附思考题.doc

课程设计(综合实验)报告( 2015 - 2016 年度第 1 学期)名 称： 操作系统综合实验 题 目： oslab综合实验 院 系： 计算机系 班 级： 学 号： 学生姓名： 指导教师： 设计周数： 分散进行 成 绩： 日期： 2015 年 10 月 29 日 实验1 实验环境的使用 一、 综合实验的目的与要求l 熟悉操作系统集成实验环境OS Lab 的基本使用方法。 l 练习编译、调试EOS 操作系统内核以及EOS 应用程序。 二、实验正文1.启动 OS Lab 2.1 执行项目 Windows 控制台窗口内容显示2.2 调试项目 2.2.1 使用断点中断执行 2.2.2 单步调试 2.2.2 .3单步调试 结果显示：练习使用“逐语句”功能和“跳出”功能 2.2.3 查看变量的值 快速监视 添加监视2.2.4 调用堆栈调用堆栈显示内容进入Func 函数双击 main 函数所在的行表示此函数是当前调用堆栈中的活动函数。 3 新建EOS 内核项目4 EOS 应用程序项目的生成和调试4.1 新建EOS 应用程序项目 4.2 调试项目 添加断点后单步调试结果显示 4.3 查看软盘镜像文件中的内容 4.4修改EOS 应用程序项目名称 5 退出OS Lab6 保存EOS 内核项目 三、综合实验总结或结论思考与练习：1. 在哪些情况下应该使用“逐过程”调试，在哪些情况下应该使用“逐语句”调试。答：逐语句为每执行一行语句，如果碰到函数调用它就会进入到函数里面。而逐过程碰到函数时不进入函数，把函数调用当成一条语句去执行。2. 生成EOS SDK 文件夹的目的和作用。明白文件夹的组织结构和各个文件的来源和作用。查看EOS 应用程序包含了SDK 文件夹中的哪些头文件，是如何包含的？（1）EOSSDK为应用程序调用系统API提供服务，可作为用户编程中使用的工具包集合。（2）其主要包括INC头文件LIB文件夹、导入库文件和BIN文件夹、动态链接库、可执行程序、二进制文件。（3）包含的头文件有:eos.h负责导出API函数,eosdef.h声明负责导出函数类型的定义,error.h负责导出错误码。 （4）EOS应用程序在项目的头文件中只是包含了eos.h文件，在eos.h文件中又包含了eosdef.h和error.h文件。实验 2 操作系统的启动一、 综合实验的目的与要求跟踪调试 EOS 在 PC 机上从加电复位到成功启动全过程，了解操作系统的启动过程。查看 EOS 启动后的状态和行为，理解操作系统启动后的工作方式。二、实验正文1. 准备实验新建一个 EOS Kernel 项目。打开boot.asm 和loader.asm 两个汇编文件。生成项目。找到loader.bin 文件，记录下此文件的大小 1566 字节。2 调试 EOS 操作系统的启动过程2.1 使用 Bochs 做为远程目标机找到“远程目标机”属性，将此属性值修改为“BochsDebug”2.2 调试 BIOS 程序2.2.1在 Console 窗口中输入调试命令 sreg 后按回车，其中 CS 寄存器信息行中的“ s=0xf000”表示 CS 寄存器的值为 0xf000。2.2.2 输入调试命令 r 后按回车，显示当前 CPU 中各个通用寄存器的值。其中“ rip:0x00000000:0000fff0”表示 IP 寄存器的值为 0xfff0。2.2.3输入调试命令 xp /1024b 0x0000，查看开始的 1024 个字节的物理内存。在 Console 中输出的这1K 物理内存的值都为 0，说明 BIOS 中断向量表还没有被加载到此处。2.2.4输入调试命令 xp /512b 0x7c00，查看软盘引导扇区应该被加载到的内存位置。输出的内存值都为 0，说明软盘引导扇区还没有被加载到此处。可以验证 BIOS 第一条指令所在逻辑地址中的段地址和 CS 寄存器值是一致的，偏移地址和 IP 寄存器值是一致的。由于内存还没有被使用，所以其中的值都为 0。2.3 调试软盘引导扇区程序2.3.1. 输入调试命令 vb 0x0000:0x7c00，添加断点2.3.2. 输入调试命令 c 继续执行2.3.3. 输入调试命令 sreg 验证 CS 寄存器（ 0x0000）的值。2.3.4. 输入调试命令 r 验证 IP 寄存器（ 0x7c00）的值。2.3.5输入调试命令 xp /1024b 0x0000 验证此时 BIOS 中断向量表已经被载入。2.3.6.输入调试命令 xp /512b 0x7c00 显示软盘引导扇区程序的所有字节码。2.3.7输入调试命令 xp /512b 0x0600 验证图 3-2 中第一个用户可用区域是空白的。2.3.8输入调试命令 xp /512b 0x7e00 验证图 3-2 中第二个用户可用区域是空白的。2.3.9 自己设计两个查看内存的调试命令，验证这两个用户可用区域的高地址端是空白的。(1) xp /512b 0x7f00 (2) xp /512b0x0700 2.3.10输入调试命令 xp /512b 0xa0000 验证图 3-2 中上位内存已经被系统占用。2.3.11自己设计一个查看内存的调试命令，验证上位内存的高地址端已经被系统占用。xp /512b 0xb0000 2.3.12 输入调试命令 xp /8b 0x1000 查看内存 0x1000 处的数据，验证此块内存的前三个字节和 loader.lst文件中的第一条指令的字节码是相同的。2.3.13根据之前记录的 loader.bin 文件的大小，自己设计一个查看内存的调试命令loader.bin文件的大小为1566个字节，转换为十六进制的61E，所以程序最后八个字节在物理内存的0x1616到0x161D的位置，所以调试命令为xp/8b 0x1616。经检验， loader.bin程序结束位置字节码与反汇编命令相同。注：查看loader.bin文件的大小应在“属性”对话框中看。2.4 调试加载程序使用查看虚拟内存的调试命令 x /1wx 0x80001117 查看内存中保存的 32 位函数入口地址，在Console 窗口中会输出：0x0000000080001117 : 0x800*2.5 调试内核在“监视”窗口中可以看到KiSystemStartup 函数地址为void (PVOID) 0x800* KiSystemStartup2.6 EOS 启动后的状态和行为三、综合实验总结或结论1. 为什么 EOS 操作系统从软盘启动时要使用 boot.bin 和 loader.bin 两个程序？使用一个可以吗？ 它们各自的主要功能是什么？ 如果将 loader.bin 的功能移动到 boot.bin 文件中，则 boot.bin 文件的大小是否仍然能保持小于 512 字节？答：在IDE环境启动执行EOS操作系统时，会将boot.bin，loader.bin，kernal.dll三个二进制写入软件镜像文件中,然后让虚拟机来执行软盘中的EOS操作系统,使用其中一个是不能运行的。 2.为什么软盘引导扇区程序选择将 loader.bin加载到第一个可用区域的 0x1000 处呢？这样做有什么好处？这样做会对 loader.bin 文件的大小有哪些限制。答：用户只用两个可用区域，加载位置非此即彼。第一个可用用户区是低地址区，且空间大小比较小，适合容纳小文件，所以我们选择将占用空loder.bin加载到第一用户区。优点:低地址开始，便于搜索查找小文件占用小空间，节约资源。限制:loder.bin文件必须小于 1c00k。实验 3 进程的创建一、 综合实验的目的与要求练习使用 EOS API 函数 CreateProcess 创建一个进程，掌握创建进程的方法，理解进程和程序的区别。调试跟踪 CreateProcess 函数的执行过程，了解进程的创建过程，理解进程是资源分配的单位。二、实验正文1 准备实验2 练习使用控制台命令创建 EOS 应用程序的进程 Hello.exe 应用程序输出结果3 练习通过编程的方式让应用程序创建另一个应用程序的进程可知子进程结束后，父进程继续执行4 调试 CreateProcess 函数在“反汇编”窗口的左侧显示的虚拟地址中看到所有指令的虚拟地址都大于 0x80000000，说明内核（ kernel.dll） 处于高 2G 的虚拟地址空间中。查看 main 函数的指令所在的虚拟地址都是小于 0x80000000，说明应用程序（ eosapp.exe）处于低 2G 的虚拟地址空间中。5 调试 PsCreateProcess 函数进程执行的结果:绘制一幅进程创建过程的流程图。6 练习通过编程的方式创建应用程序的多个进程多个进程并发执行的结果:有结果显示可知有两个进程在执行三、综合实验总结或结论1. 在源代码文件 NewTwoProc.c 提供的源代码基础上进行修改，要求使用 hello.exe 同时创建 10 个进程。修改结果如下图所示： 部分修改代码如下图所示：（“”部分为相似的4-9进程代码） if (CreateProcess(A:Hello.exe, NULL, 0, &StartupInfo, &ProcInfoOne)& CreateProcess(A:Hello.exe, NULL, 0, &StartupInfo, &ProcInfoTwo)& CreateProcess(A:Hello.exe, NULL, 0, &StartupInfo, &ProcInfo3) & CreateProcess(A:Hello.exe, NULL, 0, &StartupInfo, &ProcInfo10) WaitForSingleObject(ProcInfoOne.ProcessHandle, INFINITE);WaitForSingleObject(ProcInfoTwo.ProcessHandle, INFINITE);WaitForSingleObject(ProcInfo3.ProcessHandle, INFINITE);WaitForSingleObject(ProcInfo10.ProcessHandle, INFINITE);GetExitCodeProcess(ProcInfoOne.ProcessHandle, &ulExitCode); GetExitCodeProcess(ProcInfo3.ProcessHandle, &ulExitCode);printf(nThe process 3 exit with %d.n, ulExitCode); GetExitCodeProcess(ProcInfo10.ProcessHandle, &ulExitCode);printf(nThe process 10 exit with %d.n, ulExitCode);CloseHandle(ProcInfoOne.ProcessHandle); CloseHandle(ProcInfoTwo.ThreadHandle);CloseHandle(ProcInfo3.ProcessHandle);CloseHandle(ProcInfo3.ThreadHandle); CloseHandle(ProcInfo10.ProcessHandle);CloseHandle(ProcInfo10.ThreadHandle);2. 在 PsCreateProcess 函 数 中 调 用 了 PspCreateProcessEnvironment 函 数 后 又 先 后 调 用 了PspLoadProcessImage 和 PspCreateThread 函数， 学习这些函数的主要功能。能够交换这些函数被调用的顺序吗？答：PspCreateProcessEnvironment创建了进程控制块，地址空间和分配了句柄表，PspLoadProcessImage将进程的可执行映象加载的到了进程的地址空间中，PspCreateThread 创建了进程的主线程。这三个函数知道自己从哪里开始执行，执行哪些指令，因此不能交换它们的顺序。 实验 4 线程的状态和转换一、 综合实验的目的与要求调试线程在各种状态间的转换过程，熟悉线程的状态和转换。通过为线程增加挂起状态，加深对线程状态的理解。二、实验正文1 准备实验2 调试线程状态的转换过程2.1 线程由阻塞状态进入就绪状态“ *Thread”State 域的值为 3（ Waiting）， 双向链表项 StateListEntry的 Next 和 Prev 指针的值都不为 0， 说明这个线程还处于阻塞状态，并在某个同步对象的等待队列中； StartAddr 域的值为IopConsoleDispatchThread，说明这个线程就是控制台派遣线程。在“调用堆栈”窗口中双击 PspUnwaitThread 函数对应的堆栈项， 按F10调试，此时 State 域的值为 0（ Zero）， 双向链表项 StateListEntry 的 Next 和 Prev 指针的值都为 0， 说明这个线程已经处于游离状态。按 F5 继续执行， 在 PspReadyThread 函数中的断点处中断。按 F10 单步调试直到此函数的最后。此时 State 域的值为 1（ Ready），双向链表项 StateListEntry 的 Next 和 Prev 指针的值都不为 0，说明这个线程已经处于就绪状态，并已经被放入优先级为 24 的就绪队列中。 2.2 线程由运行状态进入就绪状态2.3 线程由就绪状态进入运行状态2.4 线程由运行状态进入阻塞状态3 为线程增加挂起状态三、综合实验总结或结论1. 思考一下，在本实验中，当 loop 线程处于运行状态时， EOS 中还有哪些线程，它们分别处于什么状态。可以使用控制台命令 pt 查看线程的状态。答：有一个优先级为0的空闲线程处于就绪状态，8个优先级为24的控制台线程处于阻塞状态，1个优先级的24的控制台派遣线程处于阻塞状态 。2. 当 loop 线程在控制台 1 中执行，并且在控制台 2 中执行 suspend 命令时，为什么控制台 1 中的 loop线程处于就绪状态而不是运行状态？答：在控制台 2 中执行 suspend 命令时，优先级为24的控制台2线程抢占处理器，即控制台2线程处于运行状态，因此此时loop处于就绪状态。3. 总结一下在图 5-3 中显示的转换过程，哪些需要使用线程控制块中的上下文，哪些不需要使用， 并说明原因。答：就绪运行，运行就绪，运行阻塞需要使用TCB因为这些过程有线程调进或调出处理机的过程，新建就绪，阻塞就绪不需要使用TCB上下文，因为没有占用处理机资源。 4. 请读者找出这些转换过程的原语操作（关中断和开中断） 是在哪些代码中完成的。答：IntState=KeEnableInterrupts(FALSE);/关中断 KeEnableInterrupts(IntState);/开中断实验 5 进程的同步1、 综合实验的目的与要求使用 EOS 的信号量， 编程解决生产者消费者问题，理解进程同步的意义。调试跟踪 EOS 信号量的工作过程，理解进程同步的原理。修改 EOS 的信号量算法，使之支持等待超时唤醒功能，加深理解进程同步的原理。2、 实验正文1 准备实验2 使用 EOS 的信号量解决生产者消费者问题3 调试 EOS 信号量的工作过程3.1 创建信号量PsInitializeSemaphore 函数中用来初始化信号量结构体成员的值，应该和传入 CreateSemaphore 函数的参数值是一致的。单步调试 PsInitializeSemaphore 函数执行的过程，函数的调用层次：先再3.2 等待、释放信号量3.2.1 等待信号量（不阻塞）完成 PsWaitForSemaphore 函数中所有操作。 Empty的计数减少了 1（由 10 变为了 9）3.2.2 释放信号量（不唤醒）完成 PsReleaseSemaphore 函数中的所有操作。 Full计数增加了 1（由 0 变为了 1）。3.2.3 等待信号量（阻塞）在“调用堆栈”窗口中双击 Producer 函数所在的堆栈帧，绿色箭头指向等待 Empty 信号量的代码行，查看 Producer 函数中变量 i 的值为 14，表示生产者线程正在尝试生产 14 号产品。在“调用堆栈”窗口中双击 PsWaitForSemaphore 函数的堆栈帧，查看 Empty 信号量计数（ Semaphore-Count）的值为-1.3.2.4 释放信号量（唤醒）Consumer 函数中变量 i 的值为 4，说明已经消费了 4 号产品。查看 PsReleaseSemaphore 函数中 Empty 信号量计数（ Semaphore-Count）的值为-1，和生产者线程被阻塞时的值是一致的。单步调试 PsReleaseSemaphore 函数，Empty计数的值已经由-1增加为了04 修改 EOS 的信号量算法（1）修改 PsWaitForSemaphore 函数：if(Semaphore-Count0) Semaphore-Count-; flag=STATUS_SUCCESS; else flag=PspWait(&Semaphore-WaitListHead,Milliseconds); KeEnableInterrupts(IntState); returnflag;（2）修改PsReleaseSemaphore函数：while(!ListIsEmpty(&Semaphore-WaitListHead)&(ReleaseCount)PspWakeThread(&Semaphore-WaitListHead,STATUS_SUCCESS);PspThreadSchedule();ReleaseCount-;Semaphore-Count=Semaphore-Count+ReleaseCount;Status=STATUS_SUCCESS;KeEnableInterrupts(IntState);returnStatus;测试结果:根据文档中的测试方法可看到结果中有两个消费者三、综合实验总结或结论1. 思考在 ps/semaphore.c 文件内的 PsWaitForSemaphore 和 PsReleaseSemaphore 函数中，为什么要使用原子操作？答：EOS内核中维护了大量内核数据，正是这些数据描述了EOS操作系统的状态如果有一组相互关联的内核数据共同描述了这个操作系统的某个状态，那么在修改这样一组内核数据时就必须保证一致性。这就要求修改这部分数据的代码在执行过程中不能被打断，这种操作叫做“原语操作”。 2. 根据本实验 3.3.2 节中设置断点和调试的方法，自己设计一个类似的调试方案来验证消费者线程在消费 24 号产品时会被阻塞，直到生产者线程生产了 24 号产品后，消费者线程才被唤醒并继续执行的过程。答： 生产到23号产品后，进程阻塞。实验 6 时间片轮转调度1、 综合实验的目的与要求调试 EOS 的线程调度程序，熟悉基于优先级的抢先式调度。为 EOS 添加时间片轮转调度，了解其它常用的调度算法。二、实验正文1 准备实验2 阅读控制台命令“rr”相关的源代码3 调试线程调度程序3.1 调试当前线程不被抢先的情况查看 ThreadFunction 函数中变量 pThreadParameter-Y 的值应该为 0，说明正在调试的是第 0个新建的线程。按2次 F5 的循环输出的内容： 以二进制格式查看就绪位图的值BitScanReverse 函数会从就绪位图中扫描最高优先级，并保存在变量HighestPriority 中。查看变量 HighestPriority 的值为 8。3.2 调试当前线程被抢先的情况激活虚拟机窗口，可以看到第 0 个新建的线程正在执行。在“监视”窗口中查看就绪位图的值为 1000000000000000100000001，说明此时在优先级为 24的 就 绪 队 列 中 存 在 就 绪 线 程 。 在 “ 监 视 ” 窗 口 中 添 加 表 达 式“ ListGetCount(&PspReadyListHeads24) ”，其值为 1，说明优先级为 24 的就绪队列中只有一个就绪线程。扫描就绪位图后获得的最高优先级的值 HighestPriority 也就应该是 24。显示0x18=24继续调试优先级24 的线程已经进入了“运行”状态。4 为 EOS 添加时间片轮转调度修改部分代码：VOIDPspRoundRobin(VOID) if(NULL!=PspCurrentThread&Running=PspCurrentThread-State)PspCurrentThread-RemainderTicks-; if(0=PspCurrentThread-RemainderTicks) PspCurrentThread-RemainderTicks=TICKS_OF_TIME_SLICE; if(BIT_TEST(PspReadyBitmap,PspCurrentThread-Priority)PspReadyThread(PspCurrentThread);测试：能看到 20 个线程轮流执行的效果5 修改线程时间片的大小执行的效果： 参数=20 参数=100 时间片过大，算法便退化成为先进先出算法。三、综合实验总结或结论1. 结合线程调度执行的时机，说明在 ThreadFunction 函数中，为什么可以使用“关中断”和“开中断”方法来保护控制台这种临界资源。结合线程调度的对象说明这样做的原因。答：EOS会设置CPU停止响应外部设备产生的硬中断，也就不会在由硬中断触发线程调度。开中断和关中断使处理机在这段时间屏蔽掉了外界所有中断，使他线程无法占用资源。使用开中断和关中断进程同步不会改变线程状态，可以保证那些没有获得处理器的资源都在就绪队列中。2.为什么不需要将被中断线程转入“就绪”状态？如果此时将被中断线程转入了“就绪”状态又会怎么样？可以结合 PspRoundRobin 函数和 PspSelectNextThread 函数的流程进行思考，并使用抢先和不抢先两种情况进行说明。答：（1）因为其他优先队列的线程等待时间不能过长。(2)若将中断线程转入就绪队列，只有当此线程执行完毕之后，其他队列的线程才有机会进入就绪队列，尤其是当其他就绪队列中的线程关于人机交互的时候，会严重影响用户体验。3. EOS 内核时间片大小取 60ms，在线程比较多时，就可以观察出线程轮流执行的情况，但是在 Windows、Linux 等操作系统启动后，正常情况下都有上百个线程在并发执行，为什么觉察不到它们被轮流执行，并且每个程序都运行的很顺利呢？答：因为时间片选取合适，线程轮流运行，体现了其虚拟性。实验 7 物理存储器与进程逻辑地址空间的管理1、 综合实验的目的与要求通过查看物理存储器的使用情况，并练习分配和回收物理内存，从而掌握物理存储器的管理方法。通过查看进程逻辑地址空间的使用情况，并练习分配和回收虚拟内存， 从而掌握进程逻辑地址空间的管理方法。2、 实验正文1 准备实验2 阅读控制台命令“pm”相关的源代码，并查看其执行的结果3 分配物理页和释放物理页按 F10 单步调试 MiAllocateAnyPages 函数的执行过程,结果如图可知其空闲页为7126，零页链表为0，已用表为1050.按 F10 单步调试 MiFreePages 函数的执行过程，结果如图可知其再分配1页后，空闲页为7125，零页链表为0，已用表为1051，即用空闲页分配，没用零页链表分配。4 阅读控制台命令“vm”相关的源代码，并查看其执行的结果输入命令“ A: LoopApp.exe”后按回车。 此时就使用 EOS 应用程序文件 LoopApp.exe 创建了一个应用程序进程，由于此进程执行了一个死循环，所以此进程不会结束执行，除非关闭虚拟机。5 在系统进程中分配虚拟页和释放虚拟页调试释放虚拟页的过程：BaseAddress 由初始化的变成了和 RegionSize由初始化的变成了。在调用 MmAllocateVirtualMemory 函数时将 RegionSize 参数的值设置为PAGE_SIZE*2+1，观察“输出”窗口中转储的信息，输出文本略。3、 综合实验总结或结论1. 在本实验 3.3 中，如果分配了物理页后，没有回收，会对 EOS 操作系统造成什么样的影响？ 目前 EOS操作系统内核函数 MiAllocateAnyPages 能处理所有物理页被分配完毕的情况吗？答：(1)会造成自由页链表和零链表不断减少，甚至为空。所有物理页都分配完毕的现象。(2)不能。 2. 尝试从性能的角度分析内核函数 MiAllocateAnyPages 和 MiAllocateZeroedPages。 尝试从安全性的角度分析分配零页的必要性。答： MiAllocateAnyPages 分配物理页。首先从空闲页链表中分配，如果分配空闲链表不足则再从零页链表分配。MiAllocateZeroedPages首先从零页链表中分配，如果零页不足则从空闲链表分配。 3. 观察本实验 3.4 中使用“ vm” 命令输出的系统进程的虚拟地址描述符，可以看到在 2 号描述符和 3 号描述符之间有两个虚拟页的空隙，尝试结合虚拟页的分配和释放说明产生这个空隙的原因。答：产生空隙是由于虚拟页被释放而造成的。在启动时会有一个初始化线程在初始化完毕之后就退出了，线程的堆栈所占用的虚拟页也就被释放了。 4. 在本实验 3.5 中，调用 MmAllocateVirtualMemory 函数分配虚拟页时只使用了 MEM_RESERVE 标志，没有使用 MEM_COMMIT 标志，尝试说明这两个标志的区别。答：使用MEM_RESERVE标志分配虚拟页时，没有为其映射实际的物理页。使用MEM_COMMIT标志分配虚拟页时，会为其映射实际的物理页。实验 8 分页存储器管理1、 综合实验的目的与要求学习 i386 处理器的二级页表硬件机制，理解分页存储器管理原理。查看 EOS 应用程序进程和系统进程二级页表映射信息，理解页目录和页表的管理方式。编程修改页目录和页表的映射关系，理解分页地址变换原理。2、 实验正文1 准备实验2 查看 EOS 应用程序进程的页目录和页表验证结果与指导教程的二级页表映射信息结果相同。（输出文本略）3 查看应用程序进程和系统进程并发时的页目录和页表 （输出文本略）4 查看应用程序进程并发时的页目录和页表 （输出文本略）5 在二级页表中映射新申请的物理页 （输出文本略）3、 综合实验总结或结论1. 观察之前输出的页目录和页表的映射关系，可以看到页目录的第 0x300 个 PDE 映射的页框号就是页目录本身，说明页目录被复用为了页表。而恰恰就是这种映射关系决定了 4K 的页目录映射在虚拟地址空间的 0xC0300000-0xC0300FFF,4M 的页表映射在 0xC0000000-0xC03FFFFF。现在，假设修改了页目录，使其第 0x100 个 PDE 映射的页框号是页目录本身，此时页目录和页表会映射在 4G 虚拟地址空间的什么位置呢？答：页目录占用1个物理页，页框号是0x409.页表占用5个物理页，页框号是0x41D,0x401，0x403，0x404，0x402.2. 思考页式存储管理机制的优缺点。答：优点:虚存量大，适合多道程序运行，动态页式管理提供了内外存统一管理的虚存实现方式。内存利用率高，不要求作业连续存放，有效地解决了内存碎片问题。缺点：要进行页面中断缺页中断等处理，系统开销较大，有可能产生”抖动”现象。地址变换机构复杂，一般采用硬件实现，添加了机器成本。 实验 10 磁盘调度算法1、 综合实验的目的与要求通过学习 EOS 实现磁盘调度算法的机制，掌握磁盘调度算法执行的条件和时机。观察 EOS 实现的 FCFS、 SSTF 和 SCAN 磁盘调度算法，了解常用的磁盘调度算法。编写 CSCAN 和 N-Step-SCAN 磁盘调度算法，加深对各种扫描算法的理解。2、 实验正文1 准备实验验证先来先服务（ FCFS）磁盘调度算法：目前磁头初始停留在磁道 10，其它被阻塞的线程依次访问磁道 8、21、9、78、0、41、 10、67、12、10。调试结果如下：输出Start Cylinder: 10TID: 31 Cylinder: 8 Offset: 2 -TID: 32 Cylinder: 21 Offset: 13 +TID: 33 Cylinder: 9 Offset: 12 -TID: 34 Cylinder: 78 Offset: 69 +TID: 35 Cylinder: 0 Offset: 78 -TID: 36 Cylinder: 41 Offset: 41 +TID: 37 Cylinder: 10 Offset: 31 -TID: 38 Cylinder: 67 Offset: 57 +TID: 39 Cylinder: 12 Offset: 55 -TID: 40 Cylinder: 10 Offset: 2 -3 验证最短寻道时间优先（ SSTF）磁盘调度算法输出结果Start Cylinder: 10TID: 37 Cylinder: 10 Offset: 0 =TID: 40 Cylinder: 10 Offset: 0 =TID: 33 Cylinder: 9 Offset: 1 -TID: 31 Cylinder: 8 Offset: 1 -TID: 39 Cylinder: 12 Offset: 4 +TID: 32 Cylinder: 21 Offset: 9 +TID: 36 Cylinder: 41 Offset: 20 +TID: 38 Cylinder: 67 Offset: 26 +TID: 34 Cylinder: 78 Offset: 11 +TID: 35 Cylinder: 0 Offset: 78 -即以10 9 8 12 21 41 67 78 0 的顺序寻道4 验证 SSTF 算法造成的线程“饥饿”现象修改函数中的源代码，使磁头初始停留在磁道 10，而让其它线程依次访问磁道 78、21、9、8、11、41、10、67、12、10。输出结果：Start Cylinder: 10TID: 37 Cylinder: 10 Offset: 0 =TID: 40 Cylinder: 10 Offset: 0 =TID: 33 Cylinder: 9 Offset: 1 -TID: 34 Cylinder: 8 Offset: 1 -TID: 35 Cylinder: 11 Offset: 3 +TID: 39 Cylinder: 12 Offset: 1 +TID: 32 Cylinder: 21 Offset: 9 +TID: 36 Cylinder: 41 Offset: 20 +TID: 38 Cylinder: 67 Offset: 26 +TID: 31 Cylinder: 78 Offset: 11 +即以10 9 8 11 12 21 41 67 78的顺序寻道可以发现，虽然访问 78 号磁道的线程的请求第一个被放入请求队列，但却被推迟到最后才被处理，出现了“饥饿”现象。如果不断有新线程的请求到达并被优先满足，则访问 78 号磁道的线程的“饥饿”情况就会更加严重。5 验证扫描（ SCAN）磁盘调度算法输出结果：Start Cylinder: 10TID: 37 Cylinder: 10 Offset: 0 =TID: 40 Cylinder: 10 Offset: 0 =TID: 39 Cylinder: 12 Offset: 2 +TID: 32 Cylinder: 21 Offset: 9 +TID: 36 Cylinder: 41 Offset: 20 +TID: 38 Cylinder: 67 Offset: 26 +TID: 34 Cylinder: 78 Offset: 11 +TID: 33 Cylinder: 9 Offset: 69 -TID: 31 Cylinder: 8 Offset: 1 -TID: 35 Cylinder: 0 Offset: 8 -即以10 12 21 41 67 78 9 8 0的顺序寻道6 改写 SCAN 算法改写代码（部分）：PREQUEST pNextRequest=NULL,pNextRequest1=NULL,pNextRequest2 = NULL; for (pListEntry = RequestListHead.Next; pListEntry != &RequestListHead;pListEntry = pListEntry-Next) pRequest = CONTAINING_RECORD(pListEntry, REQUEST, ListEntry); Offset = pRequest-Cylinder - CurrentCylinder;if (0 = Offset) pNextRequest = pRequest;goto RETURN; if (Offset 0) if (Offset InsideShortestDistance) InsideShortestDistance = Offset; pNextRequest1 = pRequest; if (Offset 0) if (-Offset Next) pRequest = CONTAINING_RECORD(pListEntry, REQUEST, ListEntry); Offset = pRequest-Cylinder - CurrentCylinder; if (Offset=0)pNextRequest = pRequest;goto RETURN; else if (Offset 0 & Offset InsideShortestDistance) InsideShortestDistance = Offset;pNextRequestInside = pRequest;else if (Offset OutsideLongestDistance) OutsideLongestDistance = -Offset; pNextRequestOutside = pRequest; ScanInside=1;if(pNextRequestInside != NULL) pNextRequest = pNextRequestInside; elsepNextRequest = pNextRequestOutside;RETURN: return pNextRequest; 输出结果：Start Cylinder: 10TID: 37 Cylinder: 10 Offset: 0 =TID: 40 Cylinder: 10 Offset: 0 =TID: 39 Cylinder: 12 Offset: 2 +TID: 32 Cylinder: 21 Offset: 9 +TID: 36 Cylinder: 41 Offset: 20 +TID: 38 Cylinder: 67 Offset: 26 +TID: 34 Cylinder: 78 Offset: 11 +TID: 35 Cylinder: 0 Offset: 78 -TID: 31 Cylinder: 8 Offset: 8 +TID: 33 Cylinder: 9 Offset: 1 +即以10 12 21 41 67 78 0 8 9的顺序寻道8 验证 SSTF、 SCAN 及 CSCAN 算法中的“磁臂粘着”现象输出结果：Start Cylinder: 10TID: 32 Cylinder: 10 Offset: 0 =TID: 33 Cylinder: 10 Offset: 0 =TID: 34 Cylinder: 10 Offset: 0 =TID: 35 Cylinder: 10 Offset: 0 =TID: 36 Cylinder: 10 Offset: 0 =TID: 37 Cylinder: 10 Offset: 0 =TID: 38 Cylinder: 10 Offset: 0 =TID: 39 Cylinder: 10 Offset: 0 =TID: 40 Cylinder: 10 Offset: 0 =TID: 31 Cylinder: 78 Offset: 68 +即以10 10 10 10 10 10 10 10 10 78的顺序寻道使用 SSTF、 SCAN 和 CSCAN 算法调度这组数据，输出结果相同可以发现，虽然访问 78 号磁道的线程的请求第一个被放入请求队列，但却被推迟到最后才被处理，出现了“磁臂粘着”现象。9 编写 N-Step-SCAN 磁盘调度算法改写代码（部分）：IopDiskSchedule( VOID ) if(SubQueueRemainLength = 0) SubQueueRemainLength = SUB_QUEUE_LENGTH; for (pListEntry=RequestListHead.Next;pListEntry!=&RequestListHead & counter0;stEntry = pListEntry-Next) pRequest = CONTAINING_RECORD(pListEntry, REQUEST, ListEntry); Offset = pRequest-Cylinder - CurrentCylinder; if (0 = Offset) pNextRequest = pRequest; return pNextRequest; else if ( Offset 0 & Offset InsideShortestDistance ) InsideShortestDistance = Offset; INpNextRequest = pRequest; else if ( Offset 0 & -Offset OutsideShortestDistance ) OutsideShortestDistance = -Offset; OUTpNextRequest = pRequest; counter-; 输出结果：Start Cylinder: 10TID: 32 Cylinder: 21 Offset: 11 +TID: 36 Cylinder: 41 Offset: 20 +TID: 34 Cylinder: 78 Offset: 37 +TID: 33 Cylinder: 9 Offset: 69 -TID: 31 Cylinder: 8 Offset: 1 -TID: 35 Cylinder: 0 Offset: 8 -TID: 37 Cylinder: 10 Offset: 10 +TID: 40 Cylinder: 10 Offset: 0 =TID: 39 Cylinder: 12 Offset: 2 +TID: 38 Cylinder: 67 Offset: 55 +即以21 41 78 9 8 0 10 10 12 67的顺序寻道将宏定义 SUB_QUEUE_LENGTH 的值修改为 100，算法性能接近于SCAN 算法的性能，输出结果：10、10、12、21、41、67、78、9、8、0将宏定义SUB_QUEUE_LENGTH的值修改为1，算法退化为 FCFS算法，输出结果：8、21、9、78、0、41、10、67、12、10三、综合实验总结或结论1. 在执行 SCAN、 N-Step-SCAN 磁盘调度算法时，如果在 EOS 控制台中多次输入“ ds”命令，调度的顺序会发生变化，说明造成这种现象的原因尝试修改源代码，使这两种算法在多次执行时，都能确保调度的顺序一致。答：SCAN算法使用了全局变量Scaninside记录磁头的移动方向，在第一次执行ds命令时，开始磁头是由外向内移动的，结束时磁头变为由内向外移动，所以在下次执行ds命令时，开始磁头就继续从内向外移动了。N-STtep-SCAN算法是由于使用了全局变量subqueueremainlength记录第一个子队列剩余的长度，道理与上相同。修改方法：可以在函数IopProcessNextRequest中，每次检测到磁盘调度算法结束工作时,将这些全局变量恢复为默认值。四、参考文献 1 海西慧 2 EOS操作系统实验教程. 五、思想与感悟 在实验五中没有仔细阅读代码注释，找了很久的empty信号量（emptysemaphorehandle）full信号量等的代码名称，浪费了时间。 实验八为验证性实验，由于篇幅限制，输出文本没有列在实验报告中。由于时间紧，任务重，有些实验没有细细体味其中含义，部分修改代码的题目也没有来的及做。 但是从这十个实验中，我可以更深刻的理解操作系统的组成，任务，作用等知识。最后，感谢老师的悉心指导，帮助我解决了只从书本上自学不到的知识，令我受益匪浅。22