操作系統(tǒng)實驗報告附思考題

1、課程設計(綜合實驗)報告( 2015 - 2016 年度第 1 學期)名 稱： 操作系統(tǒng)綜合實驗 題 目： oslab綜合實驗 院 系： 計算機系 班 級： 學 號： 學生姓名： 指導教師： 設計周數(shù)： 分散進行 成 績： 日期： 2015 年 10 月 29 日 實驗1 實驗環(huán)境的使用 一、 綜合實驗的目的與要求l 熟悉操作系統(tǒng)集成實驗環(huán)境OS Lab 的基本使用方法。 l 練習編譯、調試EOS 操作系統(tǒng)內核以及EOS 應用程序。 二、實驗正文1.啟動 OS Lab 2.1 執(zhí)行項目 Windows 控制臺窗口內容顯示2.2 調試項目 2.2.1 使用斷點中斷執(zhí)行 2.2.2 單步調試 2.

2、2.2 .3單步調試 結果顯示：練習使用“逐語句”功能和“跳出”功能 2.2.3 查看變量的值 快速監(jiān)視 添加監(jiān)視2.2.4 調用堆棧調用堆棧顯示內容進入Func 函數(shù)雙擊 main 函數(shù)所在的行表示此函數(shù)是當前調用堆棧中的活動函數(shù)。 3 新建EOS 內核項目4 EOS 應用程序項目的生成和調試4.1 新建EOS 應用程序項目 4.2 調試項目 添加斷點后單步調試結果顯示 4.3 查看軟盤鏡像文件中的內容 4.4修改EOS 應用程序項目名稱 5 退出OS Lab6 保存EOS 內核項目 三、綜合實驗總結或結論思考與練習：1. 在哪些情況下應該使用“逐過程”調試，在哪些情況下應該使用“逐語句”調

3、試。答：逐語句為每執(zhí)行一行語句，如果碰到函數(shù)調用它就會進入到函數(shù)里面。而逐過程碰到函數(shù)時不進入函數(shù)，把函數(shù)調用當成一條語句去執(zhí)行。2. 生成EOS SDK 文件夾的目的和作用。明白文件夾的組織結構和各個文件的來源和作用。查看EOS 應用程序包含了SDK 文件夾中的哪些頭文件，是如何包含的？（1）EOS SDK為應用程序調用系統(tǒng)API提供服務，可作為用戶編程中使用的工具包集合。（2）其主要包括INC頭文件LIB文件夾、導入庫文件和BIN文件夾、動態(tài)鏈接庫、可執(zhí)行程序、二進制文件。（3）包含的頭文件有:eos.h負責導出API函數(shù),eosdef.h聲明負責導出函數(shù)類型的定義,error.

4、h負責導出錯誤碼。 （4）EOS應用程序在項目的頭文件中只是包含了eos.h文件，在eos.h文件中又包含了eosdef.h和error.h文件。實驗 2 操作系統(tǒng)的啟動一、 綜合實驗的目的與要求跟蹤調試 EOS 在 PC 機上從加電復位到成功啟動全過程，了解操作系統(tǒng)的啟動過程。查看 EOS 啟動后的狀態(tài)和行為，理解操作系統(tǒng)啟動后的工作方式。二、實驗正文1. 準備實驗新建一個 EOS Kernel 項目。打開boot.asm 和loader.asm 兩個匯編文件。生成項目。找到loader.bin 文件，記錄下此文件的大小 1566 字節(jié)。2 調試 EOS 操作系統(tǒng)的啟動過程2.1 使用 Bo

5、chs 做為遠程目標機找到“遠程目標機”屬性，將此屬性值修改為“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 個字節(jié)的物理內存。在 Console 中輸出的這1K 物理內存的值都為

6、 0，說明 BIOS 中斷向量表還沒有被加載到此處。2.2.4輸入調試命令 xp /512b 0x7c00，查看軟盤引導扇區(qū)應該被加載到的內存位置。輸出的內存值都為 0，說明軟盤引導扇區(qū)還沒有被加載到此處。可以驗證 BIOS 第一條指令所在邏輯地址中的段地址和 CS 寄存器值是一致的，偏移地址和 IP 寄存器值是一致的。由于內存還沒有被使用，所以其中的值都為 0。2.3 調試軟盤引導扇區(qū)程序2.3.1. 輸入調試命令 vb 0x0000:0x7c00，添加斷點2.3.2. 輸入調試命令 c 繼續(xù)執(zhí)行2.3.3. 輸入調試命令 sreg 驗證 CS 寄存器（ 0x0000）的值。2.3.4. 輸

7、入調試命令 r 驗證 IP 寄存器（ 0x7c00）的值。2.3.5輸入調試命令 xp /1024b 0x0000 驗證此時 BIOS 中斷向量表已經被載入。2.3.6.輸入調試命令 xp /512b 0x7c00 顯示軟盤引導扇區(qū)程序的所有字節(jié)碼。2.3.7輸入調試命令 xp /512b 0x0600 驗證圖 3-2 中第一個用戶可用區(qū)域是空白的。2.3.8輸入調試命令 xp /512b 0x7e00 驗證圖 3-2 中第二個用戶可用區(qū)域是空白的。2.3.9 自己設計兩個查看內存的調試命令，驗證這兩個用戶可用區(qū)域的高地址端是空白的。(1) xp /512b 0x7f00 (2) xp /51

8、2b0x0700 2.3.10輸入調試命令 xp /512b 0xa0000 驗證圖 3-2 中上位內存已經被系統(tǒng)占用。2.3.11自己設計一個查看內存的調試命令，驗證上位內存的高地址端已經被系統(tǒng)占用。xp /512b 0xb0000 2.3.12 輸入調試命令 xp /8b 0x1000 查看內存 0x1000 處的數(shù)據，驗證此塊內存的前三個字節(jié)和 loader.lst文件中的第一條指令的字節(jié)碼是相同的。2.3.13根據之前記錄的 loader.bin 文件的大小，自己設計一個查看內存的調試命令loader.bin文件的大小為1566個字節(jié)，轉換為十六進制的61E，所以程序最后八個字節(jié)在物理

9、內存的0x1616到0x161D的位置，所以調試命令為xp/8b 0x1616。經檢驗， loader.bin程序結束位置字節(jié)碼與反匯編命令相同。注：查看loader.bin文件的大小應在“屬性”對話框中看。2.4 調試加載程序使用查看虛擬內存的調試命令 x /1wx 0x80001117 查看內存中保存的 32 位函數(shù)入口地址，在Console 窗口中會輸出：0x0000000080001117 <bogus+ 0>: 0x800*2.5 調試內核在“監(jiān)視”窗口中可以看到KiSystemStartup 函數(shù)地址為void (PVOID) 0x800* KiSystemStartu

10、p>2.6 EOS 啟動后的狀態(tài)和行為三、綜合實驗總結或結論1. 為什么 EOS 操作系統(tǒng)從軟盤啟動時要使用 boot.bin 和 loader.bin 兩個程序？使用一個可以嗎？ 它們各自的主要功能是什么？ 如果將 loader.bin 的功能移動到 boot.bin 文件中，則 boot.bin 文件的大小是否仍然能保持小于 512 字節(jié)？答：在IDE環(huán)境啟動執(zhí)行EOS操作系統(tǒng)時，會將boot.bin，loader.bin，kernal.dll三個二進制寫入軟件鏡像文件中,然后讓虛擬機來執(zhí)行軟盤中的EOS操作系統(tǒng),使用其中一個是不能運行的。 2.為什么軟盤引導扇區(qū)程序選擇將 load

11、er.bin加載到第一個可用區(qū)域的 0x1000 處呢？這樣做有什么好處？這樣做會對 loader.bin 文件的大小有哪些限制。答：用戶只用兩個可用區(qū)域，加載位置非此即彼。第一個可用用戶區(qū)是低地址區(qū)，且空間大小比較小，適合容納小文件，所以我們選擇將占用空loder.bin加載到第一用戶區(qū)。優(yōu)點:低地址開始，便于搜索查找小文件占用小空間，節(jié)約資源。限制:loder.bin文件必須小于 1c00k。實驗 3 進程的創(chuàng)建一、 綜合實驗的目的與要求練習使用 EOS API 函數(shù) CreateProcess 創(chuàng)建一個進程，掌握創(chuàng)建進程的方法，理解進程和程序的區(qū)別。調試跟蹤 CreateProcess

12、函數(shù)的執(zhí)行過程，了解進程的創(chuàng)建過程，理解進程是資源分配的單位。二、實驗正文1 準備實驗2 練習使用控制臺命令創(chuàng)建 EOS 應用程序的進程 Hello.exe 應用程序輸出結果3 練習通過編程的方式讓應用程序創(chuàng)建另一個應用程序的進程可知子進程結束后，父進程繼續(xù)執(zhí)行4 調試 CreateProcess 函數(shù)在“反匯編”窗口的左側顯示的虛擬地址中看到所有指令的虛擬地址都大于 0x80000000，說明內核（ kernel.dll） 處于高 2G 的虛擬地址空間中。查看 main 函數(shù)的指令所在的虛擬地址都是小于 0x80000000，說明應用程序（ eosapp.exe）處于低 2G 的虛擬地址空間

13、中。5 調試 PsCreateProcess 函數(shù)進程執(zhí)行的結果:繪制一幅進程創(chuàng)建過程的流程圖。6 練習通過編程的方式創(chuàng)建應用程序的多個進程多個進程并發(fā)執(zhí)行的結果:有結果顯示可知有兩個進程在執(zhí)行三、綜合實驗總結或結論1. 在源代碼文件 NewTwoProc.c 提供的源代碼基礎上進行修改，要求使用 hello.exe 同時創(chuàng)建 10 個進程。修改結果如下圖所示： 部分修改代碼如下圖所示：（“”部分為相似的4-9進程代碼） if (CreateProcess("A:Hello.exe", NULL, 0, &StartupInfo, &ProcInfoOne)

14、&& 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

15、(ProcInfoOne.ProcessHandle, INFINITE);WaitForSingleObject(ProcInfoTwo.ProcessHandle, INFINITE);WaitForSingleObject(ProcInfo3.ProcessHandle, INFINITE);WaitForSingleObject(ProcInfo10.ProcessHandle, INFINITE);GetExitCodeProcess(ProcInfoOne.ProcessHandle, &ulExitCode); GetExitCodeProcess(ProcInfo3.P

16、rocessHandle, &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);Clo

17、seHandle(ProcInfo3.ProcessHandle);CloseHandle(ProcInfo3.ThreadHandle); CloseHandle(ProcInfo10.ProcessHandle);CloseHandle(ProcInfo10.ThreadHandle);2. 在 PsCreateProcess 函 數(shù) 中 調 用 了 PspCreateProcessEnvironment 函 數(shù) 后 又 先 后 調 用 了PspLoadProcessImage 和 PspCreateThread 函數(shù)， 學習這些函數(shù)的主要功能。能夠交換這些函數(shù)被調用的順序嗎？答：PspC

18、reateProcessEnvironment 創(chuàng)建了進程控制塊，地址空間和分配了句柄表，PspLoadProcessImage將進程的可執(zhí)行映象加載的到了進程的地址空間中，PspCreateThread 創(chuàng)建了進程的主線程。這三個函數(shù)知道自己從哪里開始執(zhí)行，執(zhí)行哪些指令，因此不能交換它們的順序。 實驗 4 線程的狀態(tài)和轉換一、 綜合實驗的目的與要求調試線程在各種狀態(tài)間的轉換過程，熟悉線程的狀態(tài)和轉換。通過為線程增加掛起狀態(tài)，加深對線程狀態(tài)的理解。二、實驗正文1 準備實驗2 調試線程狀態(tài)的轉換過程2.1 線程由阻塞狀態(tài)進入就緒狀態(tài)“ *Thread”State 域的值為 3（ Wai

19、ting）， 雙向鏈表項 StateListEntry的 Next 和 Prev 指針的值都不為 0， 說明這個線程還處于阻塞狀態(tài)，并在某個同步對象的等待隊列中； StartAddr 域的值為IopConsoleDispatchThread，說明這個線程就是控制臺派遣線程。在“調用堆?！贝翱谥须p擊 PspUnwaitThread 函數(shù)對應的堆棧項， 按F10調試，此時 State 域的值為 0（ Zero）， 雙向鏈表項 StateListEntry 的 Next 和 Prev 指針的值都為 0， 說明這個線程已經處于游離狀態(tài)。按 F5 繼續(xù)執(zhí)行， 在 PspReadyThread 函數(shù)中的斷

20、點處中斷。按 F10 單步調試直到此函數(shù)的最后。此時 State 域的值為 1（ Ready），雙向鏈表項 StateListEntry 的 Next 和 Prev 指針的值都不為 0，說明這個線程已經處于就緒狀態(tài)，并已經被放入優(yōu)先級為 24 的就緒隊列中。 2.2 線程由運行狀態(tài)進入就緒狀態(tài)2.3 線程由就緒狀態(tài)進入運行狀態(tài)2.4 線程由運行狀態(tài)進入阻塞狀態(tài)3 為線程增加掛起狀態(tài)三、綜合實驗總結或結論1. 思考一下，在本實驗中，當 loop 線程處于運行狀態(tài)時， EOS 中還有哪些線程，它們分別處于什么狀態(tài)?？梢允褂每刂婆_命令 pt 查看線程的狀態(tài)。答：有一個優(yōu)先級為0的空閑線程處于就緒狀態(tài)

21、，8個優(yōu)先級為24的控制臺線程處于阻塞狀態(tài)，1個優(yōu)先級的24的控制臺派遣線程處于阻塞狀態(tài) 。2. 當 loop 線程在控制臺 1 中執(zhí)行，并且在控制臺 2 中執(zhí)行 suspend 命令時，為什么控制臺 1 中的 loop線程處于就緒狀態(tài)而不是運行狀態(tài)？答：在控制臺 2 中執(zhí)行 suspend 命令時，優(yōu)先級為24的控制臺2線程搶占處理器，即控制臺2線程處于運行狀態(tài)，因此此時loop處于就緒狀態(tài)。3. 總結一下在圖 5-3 中顯示的轉換過程，哪些需要使用線程控制塊中的上下文，哪些不需要使用， 并說明原因。答：就緒運行，運行就緒，運行阻塞需要使用TCB因為這些過程有線程調進或調出處理機的過程，新建

22、就緒，阻塞就緒不需要使用TCB上下文，因為沒有占用處理機資源。 4. 請讀者找出這些轉換過程的原語操作（關中斷和開中斷） 是在哪些代碼中完成的。答：IntState=KeEnableInterrupts(FALSE);/關中斷 KeEnableInterrupts(IntState);/開中斷實驗 5 進程的同步1、 綜合實驗的目的與要求使用 EOS 的信號量， 編程解決生產者消費者問題，理解進程同步的意義。調試跟蹤 EOS 信號量的工作過程，理解進程同步的原理。修改 EOS 的信號量算法，使之支持等待超時喚醒功能，加深理解進程同步的原理。2、 實驗正文1 準備實驗2 使用 EOS 的信號量解

23、決生產者消費者問題3 調試 EOS 信號量的工作過程3.1 創(chuàng)建信號量PsInitializeSemaphore 函數(shù)中用來初始化信號量結構體成員的值，應該和傳入 CreateSemaphore 函數(shù)的參數(shù)值是一致的。單步調試 PsInitializeSemaphore 函數(shù)執(zhí)行的過程，函數(shù)的調用層次：先再3.2 等待、釋放信號量3.2.1 等待信號量（不阻塞）完成 PsWaitForSemaphore 函數(shù)中所有操作。 Empty的計數(shù)減少了 1（由 10 變?yōu)榱?9）3.2.2 釋放信號量（不喚醒）完成 PsReleaseSemaphore 函數(shù)中的所有操作。 Full計數(shù)增加了 1（由

24、0 變?yōu)榱?1）。3.2.3 等待信號量（阻塞）在“調用堆?！贝翱谥须p擊 Producer 函數(shù)所在的堆棧幀，綠色箭頭指向等待 Empty 信號量的代碼行，查看 Producer 函數(shù)中變量 i 的值為 14，表示生產者線程正在嘗試生產 14 號產品。在“調用堆棧”窗口中雙擊 PsWaitForSemaphore 函數(shù)的堆棧幀，查看 Empty 信號量計數(shù)（ Semaphore->Count）的值為- 釋放信號量（喚醒）Consumer 函數(shù)中變量 i 的值為 4，說明已經消費了 4 號產品。查看 PsReleaseSemaphore 函數(shù)中 Empty 信號量計數(shù)（ Se

25、maphore->Count）的值為-1，和生產者線程被阻塞時的值是一致的。單步調試 PsReleaseSemaphore 函數(shù)，Empty計數(shù)的值已經由-1增加為了04 修改 EOS 的信號量算法（1）修改 PsWaitForSemaphore 函數(shù)：if (Semaphore->Count > 0)  Semaphore->Count-;  flag=STATUS_SUCCESS;   else flag=PspWait(&Semaphore->WaitListHead, 

26、Milliseconds);  KeEnableInterrupts(IntState); return flag; （2）修改PsReleaseSemaphore函數(shù)：while (!ListIsEmpty(&Semaphore->WaitListHead)&&(ReleaseCount)PspWakeThread(&Semaphore->WaitListHead, STATUS_SUCCESS); PspThreadSchedule(); ReleaseCount-; 

27、; Semaphore->Count=Semaphore->Count+ReleaseCount; Status = STATUS_SUCCESS;  KeEnableInterrupts(IntState); return Status;測試結果:根據文檔中的測試方法可看到結果中有兩個消費者三、綜合實驗總結或結論1. 思考在 ps/semaphore.c 文件內的 PsWaitForSemaphore 和 PsReleaseSemaphore 函數(shù)中，為什么要使用原子操作？答：EOS內核中維護了大量內

28、核數(shù)據，正是這些數(shù)據描述了EOS操作系統(tǒng)的狀態(tài)如果有一組相互關聯(lián)的內核數(shù)據共同描述了這個操作系統(tǒng)的某個狀態(tài)，那么在修改這樣一組內核數(shù)據時就必須保證一致性。這就要求修改這部分數(shù)據的代碼在執(zhí)行過程中不能被打斷，這種操作叫做“原語操作”。 2. 根據本實驗 3.3.2 節(jié)中設置斷點和調試的方法，自己設計一個類似的調試方案來驗證消費者線程在消費 24 號產品時會被阻塞，直到生產者線程生產了 24 號產品后，消費者線程才被喚醒并繼續(xù)執(zhí)行的過程。答： 生產到23號產品后，進程阻塞。實驗 6 時間片輪轉調度1、 綜合實驗的目的與要求調試 EOS 的線程調度程序，熟悉基于優(yōu)先級的搶先式調度。為 EOS 添加時

29、間片輪轉調度，了解其它常用的調度算法。二、實驗正文1 準備實驗2 閱讀控制臺命令“rr”相關的源代碼3 調試線程調度程序3.1 調試當前線程不被搶先的情況查看 ThreadFunction 函數(shù)中變量 pThreadParameter->Y 的值應該為 0，說明正在調試的是第 0個新建的線程。按2次 F5 的循環(huán)輸出的內容： 以二進制格式查看就緒位圖的值BitScanReverse 函數(shù)會從就緒位圖中掃描最高優(yōu)先級，并保存在變量HighestPriority 中。查看變量 HighestPriority 的值為 8。3.2 調試當前線程被搶先的情況激活虛擬機窗口，可以看到第 0 個新建的

30、線程正在執(zhí)行。在“監(jiān)視”窗口中查看就緒位圖的值為 1000000000000000100000001，說明此時在優(yōu)先級為 24的 就 緒 隊 列 中 存 在 就 緒 線 程 。 在 “ 監(jiān) 視 ” 窗 口 中 添 加 表 達 式“ ListGetCount(&PspReadyListHeads24) ”，其值為 1，說明優(yōu)先級為 24 的就緒隊列中只有一個就緒線程。掃描就緒位圖后獲得的最高優(yōu)先級的值 HighestPriority 也就應該是 24。顯示0x18=24繼續(xù)調試優(yōu)先級24 的線程已經進入了“運行”狀態(tài)。4 為 EOS 添加時間片輪轉調度修改部分代碼：VOID P

31、spRoundRobin(  VOID  )   if(NULL!=PspCurrentThread&&Running=PspCurrentThread->State)        PspCurrentThread->RemainderTicks-;    if (0 = PspCurrentThread->RemainderTicks)  

32、  PspCurrentThread->RemainderTicks = TICKS_OF_TIME_SLICE;    if(BIT_TEST(PspReadyBitmap, PspCurrentThread->Priority)        PspReadyThread(PspCurrentThread);   測試：能看到 20 個線程輪流執(zhí)行的效果5 修改線程時間片的大小執(zhí)行的效果： 參數(shù)=20

33、 參數(shù)=100 時間片過大，算法便退化成為先進先出算法。三、綜合實驗總結或結論1. 結合線程調度執(zhí)行的時機，說明在 ThreadFunction 函數(shù)中，為什么可以使用“關中斷”和“開中斷”方法來保護控制臺這種臨界資源。結合線程調度的對象說明這樣做的原因。答：EOS會設置CPU停止響應外部設備產生的硬中斷，也就不會在由硬中斷觸發(fā)線程調度。開中斷和關中斷使處理機在這段時間屏蔽掉了外界所有中斷，使他線程無法占用資源。使用開中斷和關中斷進程同步不會改變線程狀態(tài)，可以保證那些沒有獲得處理器的資源都在就緒隊列中。2.為什么不需要將被中斷線程轉入“就緒”狀態(tài)？如果此時將被中斷線程轉入了“就緒”狀態(tài)又會怎么

34、樣？可以結合 PspRoundRobin 函數(shù)和 PspSelectNextThread 函數(shù)的流程進行思考，并使用搶先和不搶先兩種情況進行說明。答：（1）因為其他優(yōu)先隊列的線程等待時間不能過長。(2)若將中斷線程轉入就緒隊列，只有當此線程執(zhí)行完畢之后，其他隊列的線程才有機會進入就緒隊列，尤其是當其他就緒隊列中的線程關于人機交互的時候，會嚴重影響用戶體驗。3. EOS 內核時間片大小取 60ms，在線程比較多時，就可以觀察出線程輪流執(zhí)行的情況，但是在 Windows、Linux 等操作系統(tǒng)啟動后，正常情況下都有上百個線程在并發(fā)執(zhí)行，為什么覺察不到它們被輪流執(zhí)行，并且每個程序都運行的很順利呢？答

35、：因為時間片選取合適，線程輪流運行，體現(xiàn)了其虛擬性。實驗 7 物理存儲器與進程邏輯地址空間的管理1、 綜合實驗的目的與要求通過查看物理存儲器的使用情況，并練習分配和回收物理內存，從而掌握物理存儲器的管理方法。通過查看進程邏輯地址空間的使用情況，并練習分配和回收虛擬內存， 從而掌握進程邏輯地址空間的管理方法。2、 實驗正文1 準備實驗2 閱讀控制臺命令“pm”相關的源代碼，并查看其執(zhí)行的結果3 分配物理頁和釋放物理頁按 F10 單步調試 MiAllocateAnyPages 函數(shù)的執(zhí)行過程,結果如圖可知其空閑頁為7126，零頁鏈表為0，已用表為1050.按 F10 單步調試 MiFreePage

36、s 函數(shù)的執(zhí)行過程，結果如圖可知其再分配1頁后，空閑頁為7125，零頁鏈表為0，已用表為1051，即用空閑頁分配，沒用零頁鏈表分配。4 閱讀控制臺命令“vm”相關的源代碼，并查看其執(zhí)行的結果輸入命令“ A: LoopApp.exe”后按回車。 此時就使用 EOS 應用程序文件 LoopApp.exe 創(chuàng)建了一個應用程序進程，由于此進程執(zhí)行了一個死循環(huán)，所以此進程不會結束執(zhí)行，除非關閉虛擬機。5 在系統(tǒng)進程中分配虛擬頁和釋放虛擬頁調試釋放虛擬頁的過程：BaseAddress 由初始化的變成了和 RegionSize由初始化的變成了。在調用 MmAllocateVirtualMemory 函數(shù)時將

37、 RegionSize 參數(shù)的值設置為PAGE_SIZE*2+1，觀察“輸出”窗口中轉儲的信息，輸出文本略。3、 綜合實驗總結或結論1. 在本實驗 3.3 中，如果分配了物理頁后，沒有回收，會對 EOS 操作系統(tǒng)造成什么樣的影響？ 目前 EOS操作系統(tǒng)內核函數(shù) MiAllocateAnyPages 能處理所有物理頁被分配完畢的情況嗎？答：(1)會造成自由頁鏈表和零鏈表不斷減少，甚至為空。所有物理頁都分配完畢的現(xiàn)象。(2)不能。 2. 嘗試從性能的角度分析內核函數(shù) MiAllocateAnyPages 和 MiAllocateZeroedPages。 嘗試從安全性的角度分析分配零頁的必要性。答：

38、 MiAllocateAnyPages 分配物理頁。首先從空閑頁鏈表中分配，如果分配空閑鏈表不足則再從零頁鏈表分配。MiAllocateZeroedPages首先從零頁鏈表中分配，如果零頁不足則從空閑鏈表分配。 3. 觀察本實驗 3.4 中使用“ vm” 命令輸出的系統(tǒng)進程的虛擬地址描述符，可以看到在 2 號描述符和 3 號描述符之間有兩個虛擬頁的空隙，嘗試結合虛擬頁的分配和釋放說明產生這個空隙的原因。答：產生空隙是由于虛擬頁被釋放而造成的。在啟動時會有一個初始化線程在初始化完畢之后就退出了，線程的堆棧所占用的虛擬頁也就被釋放了。 4. 在本實驗 3.5 中，調用 MmAllocateVirt

39、ualMemory 函數(shù)分配虛擬頁時只使用了 MEM_RESERVE 標志，沒有使用 MEM_COMMIT 標志，嘗試說明這兩個標志的區(qū)別。答：使用MEM_RESERVE標志分配虛擬頁時，沒有為其映射實際的物理頁。使用MEM_COMMIT標志分配虛擬頁時，會為其映射實際的物理頁。實驗 8 分頁存儲器管理1、 綜合實驗的目的與要求學習 i386 處理器的二級頁表硬件機制，理解分頁存儲器管理原理。查看 EOS 應用程序進程和系統(tǒng)進程二級頁表映射信息，理解頁目錄和頁表的管理方式。編程修改頁目錄和頁表的映射關系，理解分頁地址變換原理。2、 實驗正文1 準備實驗2 查看 EOS 應用程序進程的頁目錄和頁

40、表驗證結果與指導教程的二級頁表映射信息結果相同。（輸出文本略）3 查看應用程序進程和系統(tǒng)進程并發(fā)時的頁目錄和頁表 （輸出文本略）4 查看應用程序進程并發(fā)時的頁目錄和頁表 （輸出文本略）5 在二級頁表中映射新申請的物理頁 （輸出文本略）3、 綜合實驗總結或結論1. 觀察之前輸出的頁目錄和頁表的映射關系，可以看到頁目錄的第 0x300 個 PDE 映射的頁框號就是頁目錄本身，說明頁目錄被復用為了頁表。而恰恰就是這種映射關系決定了 4K 的頁目錄映射在虛擬地址空間的 0xC0300000-0xC0300FFF,4M 的頁表映射在 0xC0000000-0xC03FFFFF?，F(xiàn)在，假設修改了頁目錄，使

41、其第 0x100 個 PDE 映射的頁框號是頁目錄本身，此時頁目錄和頁表會映射在 4G 虛擬地址空間的什么位置呢？答：頁目錄占用1個物理頁，頁框號是0x409.頁表占用5個物理頁，頁框號是0x41D,0x401，0x403，0x404，0x402.2. 思考頁式存儲管理機制的優(yōu)缺點。答：優(yōu)點:虛存量大，適合多道程序運行，動態(tài)頁式管理提供了內外存統(tǒng)一管理的虛存實現(xiàn)方式。內存利用率高，不要求作業(yè)連續(xù)存放，有效地解決了內存碎片問題。缺點：要進行頁面中斷缺頁中斷等處理，系統(tǒng)開銷較大，有可能產生”抖動”現(xiàn)象。地址變換機構復雜，一般采用硬件實現(xiàn)，添加了機器成本。 實驗 10 磁盤調度算法1、 綜合實驗的目

42、的與要求通過學習 EOS 實現(xiàn)磁盤調度算法的機制，掌握磁盤調度算法執(zhí)行的條件和時機。觀察 EOS 實現(xiàn)的 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:

43、 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 驗證最短尋道時間優(yōu)先（ SSTF）磁盤調度

44、算法輸出結果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

45、 Offset: 11 +TID: 35 Cylinder: 0 Offset: 78 -即以10 9 8 12 21 41 67 78 0 的順序尋道4 驗證 SSTF 算法造成的線程“饑餓”現(xiàn)象修改函數(shù)中的源代碼，使磁頭初始停留在磁道 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:

46、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的順序尋道可以發(fā)現(xiàn)，雖然訪問 78 號磁道的線程的請求第一個被放入請求隊列，但卻被推遲到最后才被處理，出現(xiàn)了“饑餓”現(xiàn)象。如果不斷有

47、新線程的請求到達并被優(yōu)先滿足，則訪問 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 O

48、ffset: 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;p

49、ListEntry = 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; pNextReques

50、t1 = pRequest; if (Offset < 0) if (-Offset < OutsideShortestDistance) OutsideShortestDistance = -Offset;pNextRequest2 = pRequest; if(ScanInside)if(pNextRequest1)return pNextRequest1; else ScanInside=!ScanInside;return pNextRequest2; elseif(pNextRequest2)return pNextRequest2;elseScanInside=!Sca

51、nInside;return pNextRequest1;RETURN: return pNextRequest; 得到輸出結果與上一結果相同。7 編寫循環(huán)掃描（ CSCAN）磁盤調度算法改寫代碼（部分）：IopDiskSchedule(VOID)for (pListEntry = RequestListHead.Next; pListEntry != &RequestListHead; pListEntry = pListEntry->Next) pRequest = CONTAINING_RECORD(pListEntry, REQUEST, ListEntry); Offs

52、et = pRequest->Cylinder - CurrentCylinder; if (Offset=0)pNextRequest = pRequest;goto RETURN; else if (Offset > 0 && Offset < InsideShortestDistance) InsideShortestDistance = Offset;pNextRequestInside = pRequest;else if (Offset < 0 && -Offset > OutsideLongestDistance) O

53、utsideLongestDistance = -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 =T

54、ID: 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、 SCA

55、N 及 CSCAN 算法中的“磁臂粘著”現(xiàn)象輸出結果：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 算法調度這組數(shù)據，輸出結果相同可以發(fā)現(xiàn)，雖然訪問 78 號磁道的線程的請求第一個被放入請求隊列，但卻被推遲到最后才被處理，出現(xiàn)了“磁臂