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

《操作系统实验报告附思考题.pdf》由会员分享，可在线阅读，更多相关《操作系统实验报告附思考题.pdf（23页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、 课程设计(综合实验)报告(2015-2016 年度第 1 学期)名 称：操作系统综合实验 题 目：oslab 综合实验 院 系：计算机系 班 级：学 号：学生姓名：指导教师：设计周数：分散进行 成 绩：日期：2015 年 10 月 29 日 1 实验 1 实验环境的使用 一、综合实验的目的与要求 熟悉操作系统集成实验环境 OS Lab 的基本使用方法。练习编译、调试 EOS 操作系统内核以及 EOS 应用程序。二、实验正文 1.启动 OS Lab 2.1 执行项目 Windows 控制台窗口内容显示 2.2 调试项目 2.2.1 使用断点中断执行 2.2.2 单步调试 2.2.2.3 单步调

2、试 结果显示：练习使用“逐语句”功能和“跳出”功能 2.2.3 查看变量的值 快速监视 添加监视 2.2.4 调用堆栈 调用堆栈显示内容 进入 Func 函数 双击 main 函数所在的行表示此函数是当前调用堆栈中的活动函数。3 新建 EOS 内核项目 4 EOS 应用程序项目的生成和调试 4.1 新建 EOS 应用程序项目 4.2 调试项目 添加断点后单步调试结果显示 4.3 查看软盘镜像文件中的内容 4.4 修改 EOS 应用程序项目名称 5 退出 OS Lab 6 保存 EOS 内核项目 三、综合实验总结或结论 思考与练习：1.在哪些情况下应该使用“逐过程”调试，在哪些情况下应该使用“逐

3、语句”调试。2 答：逐语句为每执行一行语句，如果碰到函数调用它就会进入到函数里面。而逐过程碰到函数时不进入函数，把函数调用当成一条语句去执行。2.生成 EOS SDK 文件夹的目的和作用。明白文件夹的组织结构和各个文件的来源和作用。查看 EOS 应用程序包含了 SDK 文件夹中的哪些头文件，是如何包含的？（1）EOS SDK 为应用程序调用系统 API 提供服务，可作为用户编程中使用的工具包集合。（2）其主要包括 INC 头文件 LIB 文件夹、导入库文件和 BIN 文件夹、动态链接库、可执行程序、二进制文件。（3）包含的头文件有:eos.h 负责导出 API 函数,eosdef.h 声明负责

4、导出函数类型的定义,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 字

5、节。2 调试 EOS 操作系统的启动过程 2.1 使用 Bochs 做为远程目标机 找到“远程目标机”属性，将此属性值修改为“BochsDebug”2.2 调试 BIOS 程序 2.2.1 在 Console 窗口中输入调试命令 sreg 后按回车，其中 CS 寄存器信息行中的“s=0 xf000”表示 CS 寄存器的值为 0 xf000。2.2.2 输入调试命令 r 后按回车，显示当前 CPU 中各个通用寄存器的值。其中“rip:0 x00000000:0000fff0”表示 IP 寄存器的值为 0 xfff0。2.2.3 输入调试命令 xp/1024b 0 x0000，查看开始的 1024

6、 个字节的物理内存。在 Console 中输出的这 1K 物理内存的值都为 0，说明 BIOS 中断向量表还没有被加载到此处。2.2.4 输入调试命令 xp/512b 0 x7c00，查看软盘引导扇区应该被加载到的内存位置。输出的内存值都为 0，说明软盘引导扇区还没有被加载到此处。3 可以验证 BIOS 第一条指令所在逻辑地址中的段地址和 CS 寄存器值是一致的，偏移地址和 IP 寄存器值是一致的。由于内存还没有被使用，所以其中的值都为 0。2.3 调试软盘引导扇区程序 2.3.1.输入调试命令 vb 0 x0000:0 x7c00，添加断点 2.3.2.输入调试命令 c 继续执行 2.3.3

7、.输入调试命令 sreg 验证 CS 寄存器（0 x0000）的值。2.3.4.输入调试命令 r 验证 IP 寄存器（0 x7c00）的值。2.3.5 输入调试命令 xp/1024b 0 x0000 验证此时 BIOS 中断向量表已经被载入。2.3.6.输入调试命令 xp/512b 0 x7c00 显示软盘引导扇区程序的所有字节码。4 2.3.7 输入调试命令 xp/512b 0 x0600 验证图 3-2 中第一个用户可用区域是空白的。2.3.8 输入调试命令 xp/512b 0 x7e00 验证图 3-2 中第二个用户可用区域是空白的。2.3.9 自己设计两个查看内存的调试命令，验证这两个

8、用户可用区域的高地址端是空白的。(1)xp/512b 0 x7f00 (2)xp/512b0 x0700 2.3.10 输入调试命令 xp/512b 0 xa0000 验证图 3-2 中上位内存已经被系统占用。5 2.3.11 自己设计一个查看内存的调试命令，验证上位内存的高地址端已经被系统占用。xp/512b 0 xb0000 2.3.12 输入调试命令 xp/8b 0 x1000 查看内存 0 x1000 处的数据，验证此块内存的前三个字节和 loader.lst 文件中的第一条指令的字节码是相同的。2.3.13 根据之前记录的 loader.bin 文件的大小，自己设计一个查看内存的调试

9、命令 loader.bin 文件的大小为 1566 个字节，转换为十六进制的 61E，所以程序最后八个字节在物理内存的 0 x1616 到 0 x161D 的位置，所以调试命令为 xp/8b 0 x1616。经检验，loader.bin程序结束位置字节码与反汇编命令相同。6 注：查看 loader.bin 文件的大小应在“属性”对话框中看。2.4 调试加载程序 使用查看虚拟内存的调试命令 x/1wx 0 x80001117 查看内存中保存的 32 位函数入口地址，在 Console 窗口中会输出：0 x0000000080001117:0 x800*2.5 调试内核 在“监视”窗口中可以看到

10、KiSystemStartup 函数地址为 void(PVOID)0 x800*KiSystemStartup 2.6 EOS 启动后的状态和行为 三、综合实验总结或结论 1.为什么 EOS 操作系统从软盘启动时要使用 boot.bin 和 loader.bin 两个程序？使用一个可以吗？它们各自的主要功能是什么？如果将 loader.bin 的功能移动到 boot.bin 文件中，则 boot.bin 文件的大小是否仍然能保持小于 512 字节？答：在 IDE 环境启动执行 EOS 操作系统时，会将 boot.bin，loader.bin，kernal.dll 三个二进制写入软件镜像文件中,

11、然后让虚拟机来执行软盘中的 EOS 操作系统,使用其中一个是不能运行的。2.为什么软盘引导扇区程序选择将 loader.bin 加载到第一个可用区域的 0 x1000 处呢？这样做有什么好处？这样做会对 loader.bin 文件的大小有哪些限制。答：用户只用两个可用区域，加载位置非此即彼。第一个可用用户区是低地址区，且空间大小比较小，适合容纳小文件，所以我们选择将占用空 loder.bin 加载到第一用户区。优点:低地址开始，便于搜索查找小文件占用小空间，节约资源。限制:loder.bin 文件必须小于 1c00k。实验 3 进程的创建 一、综合实验的目的与要求 练习使用 EOS API 函

12、数 CreateProcess 创建一个进程，掌握创建进程的方法，理解进程和程序的区别。调试跟踪 CreateProcess 函数的执行过程，了解进程的创建过程，理解进程是资源分配的单位。二、实验正文 1 准备实验 2 练习使用控制台命令创建 EOS 应用程序的进程 7 Hello.exe 应用程序输出结果 3 练习通过编程的方式让应用程序创建另一个应用程序的进程 可知子进程结束后，父进程继续执行 4 调试 CreateProcess 函数 在“反汇编”窗口的左侧显示的虚拟地址中看到所有指令的虚拟地址都大于 0 x80000000，说明内核（kernel.dll）处于高 2G 的虚拟地址空间中

13、。查看 main 函数的指令所在的虚拟地址都是小于 0 x80000000，说明应用程序（eosapp.exe）处于低 2G 的虚拟地址空间中。5 调试 PsCreateProcess 函数 进程执行的结果:绘制一幅进程创建过程的流程图。6 练习通过编程的方式创建应用程序的多个进程 多个进程并发执行的结果:有结果显示可知有两个进程在执行 三、综合实验总结或结论 1.在源代码文件 NewTwoProc.c 提供的源代码基础上进行修改，要求使用 hello.exe 同时创建 10 个进程。修改结果如下图所示：8 部分修改代码如下图所示：（“”部分为相似的 4-9 进程代码）if(CreatePro

14、cess(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);WaitForSingleObje

15、ct(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,ul

16、ExitCode);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.ProcessHand

17、le);CloseHandle(ProcInfo10.ThreadHandle);2.在 PsCreateProcess 函 数 中 调 用 了 PspCreateProcessEnvironment 函 数 后 又 先 后 调 用 了 PspLoadProcessImage 和 PspCreateThread 函数，学习这些函数的主要功能。能够交换这些函数被调用的顺序吗？答：PspCreateProcessEnvironment 创建了进程控制块，地址空间和分配了句柄表，PspLoadProcessImage 将进程的可执行映象加载的到了进程的地址空间中，PspCreateThread 创建

18、了进程的主线程。这三个函数知道自己从哪里开始执行，执行哪些指令，因此不能交换它们的顺序。9 实验 4 线程的状态和转换 一、综合实验的目的与要求 调试线程在各种状态间的转换过程，熟悉线程的状态和转换。通过为线程增加挂起状态，加深对线程状态的理解。二、实验正文 1 准备实验 2 调试线程状态的转换过程 2.1 线程由阻塞状态进入就绪状态“*Thread”State 域的值为 3（Waiting），双向链表项 StateListEntry 的 Next 和 Prev 指针的值都不为 0，说明这个线程还处于阻塞状态，并在某个同步对象的等待队列中；StartAddr 域的值为IopConsoleDis

19、patchThread，说明这个线程就是控制台派遣线程。在“调用堆栈”窗口中双击 PspUnwaitThread 函数对应的堆栈项，按 F10 调试，此时 State 域的值为 0（Zero），双向链表项 StateListEntry 的 Next 和 Prev 指针的值都为 0，说明这个线程已经处于游离状态。按 F5 继续执行，在 PspReadyThread 函数中的断点处中断。按 F10 单步调试直到此函数的最后。此时 State 域的值为 1（Ready），双向链表项 StateListEntry 的 Next 和 Prev 指针的值都不为 0，说明这个线程已经处于就绪状态，并已经被放

20、入优先级为 24 的就绪队列中。2.2 线程由运行状态进入就绪状态 2.3 线程由就绪状态进入运行状态 2.4 线程由运行状态进入阻塞状态 3 为线程增加挂起状态 三、综合实验总结或结论 1.思考一下，在本实验中，当 loop 线程处于运行状态时，EOS 中还有哪些线程，它们分别处于什么状态。可以使用控制台命令 pt 查看线程的状态。答：有一个优先级为 0 的空闲线程处于就绪状态，8 个优先级为 24 的控制台线程处于阻塞状态，1 个优先级的 24 的控制台派遣线程处于阻塞状态。2.当 loop 线程在控制台 1 中执行，并且在控制台 2 中执行 suspend 命令时，为什么控制台 1 中的

21、 loop 线程处于就绪状态而不是运行状态？1 0 答：在控制台 2 中执行 suspend 命令时，优先级为 24 的控制台 2 线程抢占处理器，即控制台 2 线程处于运行状态，因此此时 loop 处于就绪状态。3.总结一下在图 5-3 中显示的转换过程，哪些需要使用线程控制块中的上下文，哪些不需要使用，并说明原因。答：就绪运行，运行就绪，运行阻塞需要使用 TCB 因为这些过程有线程调进或调出处理机的过程，新建就绪，阻塞就绪不需要使用 TCB 上下文，因为没有占用处理机资源。4.请读者找出这些转换过程的原语操作（关中断和开中断）是在哪些代码中完成的。答：IntState=KeEnableIn

22、terrupts(FALSE);/关中断 KeEnableInterrupts(IntState);/开中断 实验 5 进程的同步 一、综合实验的目的与要求 使用 EOS 的信号量，编程解决生产者消费者问题，理解进程同步的意义。调试跟踪 EOS 信号量的工作过程，理解进程同步的原理。修改 EOS 的信号量算法，使之支持等待超时唤醒功能，加深理解进程同步的原理。二、实验正文 1 准备实验 2 使用 EOS 的信号量解决生产者消费者问题 3 调试 EOS 信号量的工作过程 3.1 创建信号量 PsInitializeSemaphore 函数中用来初始化信号量结构体成 员的值，应该和传入 Creat

23、eSemaphore 函数的参数值是一致的。单步调试 PsInitializeSemaphore 函数执行的过程，函数的调用层次：先再 3.2 等待、释放信号量 3.2.1 等待信号量（不阻塞）完成 PsWaitForSemaphore 函数中所有操作。Empty 的计数减少了 1（由 10 变为了 9）3.2.2 释放信号量（不唤醒）完成 PsReleaseSemaphore 函数中的所有操作。Full 计数增加了 1（由 0 变为了 1）。1 1 3.2.3 等待信号量（阻塞）在“调用堆栈”窗口中双击 Producer 函数所在的堆栈帧，绿色箭头指向等待 Empty 信号量的代码行，查看

24、Producer 函数中变量 i 的值为 14，表示生产者线程正在尝试生产 14 号产品。在“调用堆栈”窗口中双击 PsWaitForSemaphore 函数的堆栈帧，查看 Empty 信号量计数（Semaphore-Count）的值为-1.3.2.4 释放信号量（唤醒）Consumer 函数中变量 i 的值为 4，说明已经消费了 4 号产品。查看 PsReleaseSemaphore 函数中 Empty 信号量计数（Semaphore-Count）的值为-1，和生产者线程被阻塞时的值是一致的。单步调试 PsReleaseSemaphore 函数，Empty 计数的值已经由-1 增加为了 0

25、4 修改 EOS 的信号量算法（1）修改 PsWaitForSemaphore 函数：if(Semaphore-Count 0)Semaphore-Count-;flag=STATUS_SUCCESS;else flag=PspWait(&Semaphore-WaitListHead,Milliseconds);KeEnableInterrupts(IntState);return flag;（2）修改 PsReleaseSemaphore 函数：while(!ListIsEmpty(&Semaphore-WaitListHead)&(ReleaseCount)PspWakeThread(&S

26、emaphore-WaitListHead,STATUS_SUCCESS);PspThreadSchedule();ReleaseCount-;Semaphore-Count=Semaphore-Count+ReleaseCount;Status=STATUS_SUCCESS;KeEnableInterrupts(IntState);return Status;测试结果:根据文档中的测试方法可看到结果中有两个消费者 1 2 三、综合实验总结或结论 1.思考在 ps/semaphore.c 文件内的 PsWaitForSemaphore 和 PsReleaseSemaphore 函数中，为什么要

27、使用原子操作？答：EOS 内核中维护了大量内核数据，正是这些数据描述了 EOS 操作系统的状态如果有一组相互关联的内核数据共同描述了这个操作系统的某个状态，那么在修改这样一组内核数据时就必须保证一致性。这就要求修改这部分数据的代码在执行过程中不能被打断，这种操作叫做“原语操作”。2.根据本实验 3.3.2 节中设置断点和调试的方法，自己设计一个类似的调试方案来验证消费者线程在消费 24 号产品时会被阻塞，直到生产者线程生产了 24 号产品后，消费者线程才被唤醒并继续执行的过程。答：生产到 23 号产品后，进程阻塞。实验 6 时间片轮转调度 一、综合实验的目的与要求 调试 EOS 的线程调度程序

28、，熟悉基于优先级的抢先式调度。为 EOS 添加时间片轮转调度，了解其它常用的调度算法。二、实验正文 1 准备实验 2 阅读控制台命令“rr”相关的源代码 3 调试线程调度程序 3.1 调试当前线程不被抢先的情况 1 3 查看 ThreadFunction 函数中变量 pThreadParameter-Y 的值应该为 0，说明正在调试的是第 0 个新建的线程。按 2 次 F5 的循环输出的内容：以二进制格式查看就绪位图的值 BitScanReverse 函数会从就绪位图中扫描最高优先级，并保存在变量 HighestPriority 中。查看变量 HighestPriority 的值为 8。3.2

29、 调试当前线程被抢先的情况 激活虚拟机窗口，可以看到第 0 个新建的线程正在执行。在“监视”窗口中查看就绪位图的值为 1000000000000000100000001，说明此时在优先级为 24 的 就 绪 队 列 中 存 在 就 绪 线 程。在“监 视”窗 口 中 添 加 表 达 式“ListGetCount(&PspReadyListHeads24)”，其值为 1，说明优先级为 24 的就绪队列中只有一个就绪线程。扫描就绪位图后获得的最高优先级的值 HighestPriority 也就应该是 24。显示 0 x18=24 继续调试优先级 24 的线程已经进入了“运行”状态。4 为 EOS

30、添加时间片轮转调度 修改部分代码：VOID PspRoundRobin(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(PspCurrentT

31、hread);测试：能看到 20 个线程轮流执行的效果 1 4 5 修改线程时间片的大小 执行的效果：参数=20 参数=100 时间片过大，算法便退化成为先进先出算法。三、综合实验总结或结论 1.结合线程调度执行的时机，说明在 ThreadFunction 函数中，为什么可以使用“关中断”和“开中断”方法来保护控制台这种临界资源。结合线程调度的对象说明这样做的原因。答：EOS 会设置 CPU 停止响应外部设备产生的硬中断，也就不会在由硬中断触发线程调度。开中断和关中断使处理机在这段时间屏蔽掉了外界所有中断，使他线程无法占用资源。使用开中断和关中断进程同步不会改变线程状态，可以保证那些没有获得处

32、理器的资源都在就绪队列中。2.为什么不需要将被中断线程转入“就绪”状态？如果此时将被中断线程转入了“就绪”状态又会怎么样？可以结合 PspRoundRobin 函数和 PspSelectNextThread 函数的流程进行思考，并使用抢先和不抢先两种情况进行说明。答：（1）因为其他优先队列的线程等待时间不能过长。(2)若将中断线程转入就绪队列，只有当此线程执行完毕之后，其他队列的线程才有机会进入就绪队列，尤其是当其他就绪队列中的线程关于人机交互的时候，会严重影响用户体验。3.EOS 内核时间片大小取 60ms，在线程比较多时，就可以观察出线程轮流执行的情况，但是在 Windows、Linux

33、等操作系统启动后，正常情况下都有上百个线程在并发执行，为什么觉察不到它们被轮流执行，并且每个程序都运行的很顺利呢？答：因为时间片选取合适，线程轮流运行，体现了其虚拟性。实验 7 物理存储器与进程逻辑地址空间的管理 1 5 一、综合实验的目的与要求 通过查看物理存储器的使用情况，并练习分配和回收物理内存，从而掌握物理存储器的管理方法。通过查看进程逻辑地址空间的使用情况，并练习分配和回收虚拟内存，从而掌握进程逻辑地址空间的管理方法。二、实验正文 1 准备实验 2 阅读控制台命令“pm”相关的源代码，并查看其执行的结果 3 分配物理页和释放物理页 按 F10 单步调试 MiAllocateAnyPa

34、ges 函数的执行过程,结果如图 可知其空闲页为 7126，零页链表为 0，已用表为 1050.按 F10 单步调试 MiFreePages 函数的执行过程，结果如图 可知其再分配 1 页后，空闲页为 7125，零页链表为 0，已用表为 1051，即用空闲页分配，没用零页链表分配。4 阅读控制台命令“vm”相关的源代码，并查看其执行的结果 输入命令“A:LoopApp.exe”后按回车。此时就使用 EOS 应用程序文件 LoopApp.exe 创建了一个应用程序进程，由于此进程执行了一个死循环，所以此进程不会结束执行，除非关闭虚拟机。5 在系统进程中分配虚拟页和释放虚拟页 调试释放虚拟页的过程

35、：BaseAddress 由初始化的变成了和 RegionSize 由初始化的变成了。1 6 在调用 MmAllocateVirtualMemory 函数时将 RegionSize 参数的值设置为 PAGE_SIZE*2+1，观察“输出”窗口中转储的信息，输出文本略。三、综合实验总结或结论 1.在本实验 3.3 中，如果分配了物理页后，没有回收，会对 EOS 操作系统造成什么样的影响？目前 EOS 操作系统内核函数 MiAllocateAnyPages 能处理所有物理页被分配完毕的情况吗？答：(1)会造成自由页链表和零链表不断减少，甚至为空。所有物理页都分配完毕的现象。(2)不能。2.尝试从性

36、能的角度分析内核函数 MiAllocateAnyPages 和 MiAllocateZeroedPages。尝试从安全性的角度分析分配零页的必要性。答：MiAllocateAnyPages 分配物理页。首先从空闲页链表中分配，如果分配空闲链表不足则再从零页链表分配。MiAllocateZeroedPages 首先从零页链表中分配，如果零页不足则从空闲链表分配。3.观察本实验 3.4 中使用“vm”命令输出的系统进程的虚拟地址描述符，可以看到在 2 号描述符和 3 号描述符之间有两个虚拟页的空隙，尝试结合虚拟页的分配和释放说明产生这个空隙的原因。答：产生空隙是由于虚拟页被释放而造成的。在启动时会

37、有一个初始化线程在初始化完毕之后就退出了，线程的堆栈所占用的虚拟页也就被释放了。4.在本实验 3.5 中，调用 MmAllocateVirtualMemory 函数分配虚拟页时只使用了 MEM_RESERVE 标志，没有使用 MEM_COMMIT 标志，尝试说明这两个标志的区别。答：使用 MEM_RESERVE 标志分配虚拟页时，没有为其映射实际的物理页。使用MEM_COMMIT 标志分配虚拟页时，会为其映射实际的物理页。实验 8 分页存储器管理 一、综合实验的目的与要求 学习 i386 处理器的二级页表硬件机制，理解分页存储器管理原理。查看 EOS 应用程序进程和系统进程二级页表映射信息，理

38、解页目录和页表的管理方式。编程修改页目录和页表的映射关系，理解分页地址变换原理。二、实验正文 1 准备实验 2 查看 EOS 应用程序进程的页目录和页表 验证结果与指导教程的二级页表映射信息结果相同。（输出文本略）3 查看应用程序进程和系统进程并发时的页目录和页表（输出文本略）1 7 4 查看应用程序进程并发时的页目录和页表（输出文本略）5 在二级页表中映射新申请的物理页（输出文本略）三、综合实验总结或结论 1.观察之前输出的页目录和页表的映射关系，可以看到页目录的第 0 x300 个 PDE 映射的页框号就是页目录本身，说明页目录被复用为了页表。而恰恰就是这种映射关系决定了 4K 的页目录映

39、射在虚拟地址空间的 0 xC0300000-0 xC0300FFF,4M 的页表映射在 0 xC0000000-0 xC03FFFFF。现在，假设修改了页目录，使其第 0 x100 个 PDE 映射的页框号是页目录本身，此时页目录和页表会映射在 4G 虚拟地址空间的什么位置呢？答：页目录占用 1 个物理页，页框号是 0 x409.页表占用 5 个物理页，页框号是 0 x41D,0 x401，0 x403，0 x404，0 x402.2.思考页式存储管理机制的优缺点。答：优点:虚存量大，适合多道程序运行，动态页式管理提供了内外存统一管理的虚存实现方式。内存利用率高，不要求作业连续存放，有效地解决

40、了内存碎片问题。缺点：要进行页面中断缺页中断等处理，系统开销较大，有可能产生”抖动”现象。地址变换机构复杂，一般采用硬件实现，添加了机器成本。实验 10 磁盘调度算法 一、综合实验的目的与要求 通过学习 EOS 实现磁盘调度算法的机制，掌握磁盘调度算法执行的条件和时机。观察 EOS 实现的 FCFS、SSTF 和 SCAN 磁盘调度算法，了解常用的磁盘调度算法。编写 CSCAN 和 N-Step-SCAN 磁盘调度算法，加深对各种扫描算法的理解。二、实验正文 1 准备实验 验证先来先服务（FCFS）磁盘调度算法：目前磁头初始停留在磁道 10，其它被阻塞的线程依次访问磁道 8、21、9、78、0

41、、41、10、67、12、10。调试结果如下：输出 Start Cylinder:10 TID: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

42、-1 8 TID:40 Cylinder:10 Offset:2-3 验证最短寻道时间优先（SSTF）磁盘调度算法 输出结果 Start Cylinder:10 TID: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 Offse

43、t: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:10 TID:37 Cylinder:10 Offset:0=TID:40 Cylinder:10 Offset:0=TID:33 Cylinder:9 Offset:1-TID:34 Cyl

44、inder: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 号磁道的线程的请求第一个被放入请求队列，但却被推迟到最后才被处理，出现了“饥饿”现象。如果不断有新线程的请求到达并被优先满足，则访

45、问 78 号磁道的线程的“饥饿”情况就会更加严重。5 验证扫描（SCAN）磁盘调度算法 输出结果：Start Cylinder:10 TID: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-1 9 TI

46、D: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(pListEntr

47、y,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=pR

48、equest-Cylinder-CurrentCylinder;if(Offset=0)pNextRequest=pRequest;goto RETURN;else if(Offset 0&Offset InsideShortestDistance)InsideShortestDistance=Offset;pNextRequestInside=pRequest;else if(Offset OutsideLongestDistance)2 0 OutsideLongestDistance=-Offset;pNextRequestOutside=pRequest;ScanInside=1;if

49、(pNextRequestInside!=NULL)pNextRequest=pNextRequestInside;elsepNextRequest=pNextRequestOutside;RETURN:return pNextRequest;输出结果：Start Cylinder:10 TID: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 Cylinde

50、r: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:10 TID:32 Cylinder:10 Offset:0=TID:33 Cylinder:10 Offset:0=TID:34 Cylinder:10 Offset: