Báo cáo đồ án 3 Nachos môn Hệ điều hành - ĐH Khoa học Tự nhiên

Đồ án 3 là một cột mốc quan trọng trong môn học Hệ điều hành, tập trung vào việc triển khai cơ chế… 48 trang · Trường Đại học Khoa học Tự nhiên, ĐHQG - HCM.

• Tác giả: Bùi Phước Thiện
• Người hướng dẫn: Thầy Lê Viết Long
• Trường học: Trường Đại học Khoa học Tự nhiên, ĐHQG - HCM
• Chuyên ngành: Hệ điều hành
• Đề tài: Báo cáo đồ án 3 - Nachos
• Loại tài liệu: Đồ án
• Năm xuất bản: 2021-2022
• Địa điểm: Thành phố Hồ Chí Minh

Mục lục chi tiết

• Thông tin nhóm và công việc phân công
• 1. Mô hình quản lý tiến trình
• 1.1. Exec
• 1.2. Join
• 1.3. Exit
• 2. Các lớp cần tìm hiểu
• 2.1. PTable
• 2.2. PCB
• 2.3. BitMap
• 2.4. Thread
• 3. Các system call mà nhóm cần cài đặt thêm vào
• 3.1. Exec
• 3.2. Join
• 4. Các chỉnh sửa mà nhóm đã thực hiện ở source code
• 4.1. Khai báo các biến toàn cục mới ở system
• 4.2. Phương thức GetFreeSlot()
• 4.3. Phương thức ExecUpdate(char* filename)
• 4.4. Phương thức ExitUpdate(int ec)
• 4.5. Phương thức Exec(char *filename, int pID)
• 4.6. Phương thức MyStartProcess(int pID)
• 4.7. Viết thêm phương thức tĩnh ThreadFinish() để dọn rác cho currentThread
• 4.8. Thay đổi giá trị hằng số NumPhysPages
• 5. Chạy thử chương trình Scheduler
• 5.1. Chương trình Scheduler
• 5.2. Chương trình Ping/Pong
• 6. Những điều đã làm được
• 7. Những điều chưa làm được
• 8. Hướng dẫn sử dụng chương trình
• Tài liệu tham khảo

Tóm tắt

I. Tổng quan đồ án 3 Nachos môn học hệ điều hành chi tiết

Đồ án 3 là một cột mốc quan trọng trong môn học Hệ điều hành, tập trung vào việc triển khai cơ chế đa chương (multiprogramming) trên hệ điều hành Nachos. Nachos, viết tắt của "Not Another Completely Heuristic Operating System", là một hệ điều hành giáo dục được thiết kế để sinh viên trực tiếp trải nghiệm và xây dựng các thành phần cốt lõi của một hệ điều hành hiện đại. Mục tiêu chính của đồ án này là chuyển đổi Nachos từ một hệ thống đơn chương, chỉ có khả năng chạy một tiến trình người dùng tại một thời điểm, thành một hệ thống đa chương có thể quản lý và thực thi đồng thời nhiều tiến trình. Để đạt được mục tiêu này, sinh viên cần phải tìm hiểu sâu về source code Nachos và cài đặt các chức năng thiết yếu. Trọng tâm của báo cáo này là việc triển khai ba lời gọi hệ thống (system call) cơ bản nhưng cực kỳ quan trọng: Exec, Join, và Exit. Những system call này tạo thành nền tảng cho việc tạo, đồng bộ hóa và kết thúc tiến trình. Bên cạnh đó, việc quản lý tài nguyên hệ thống như bộ nhớ và CPU trở nên phức tạp hơn, đòi hỏi phải xây dựng các cấu trúc dữ liệu hiệu quả như bảng tiến trình (PTable) và cơ chế đồng bộ hóa tiến trình bằng semaphore trong Nachos để tránh các xung đột và đảm bảo tính toàn vẹn của hệ thống. Báo cáo này sẽ trình bày chi tiết phương pháp tiếp cận, các lớp đối tượng được sử dụng, những thay đổi trong mã nguồn và kết quả thực nghiệm để minh chứng cho sự thành công của việc triển khai. Đây là một tài liệu Nachos tiếng Việt hữu ích cho các sinh viên đang thực hiện đồ án hệ điều hành tương tự.

1.1. Giới thiệu về hệ điều hành giáo dục Nachos

Hệ điều hành Nachos là một framework phần mềm cung cấp bộ khung cho một hệ điều hành, cho phép sinh viên điền vào các phần còn thiếu để hoàn thiện các chức năng. Nó được viết bằng C++ và chạy trên một máy ảo mô phỏng kiến trúc MIPS. Mục đích của Nachos không phải là một hệ điều hành thương mại mà là một công cụ sư phạm, giúp sinh viên hiểu rõ các khái niệm trừu tượng như luồng (thread) trong Nachos, quản lý tiến trình, lập lịch CPU, và quản lý bộ nhớ. Trong bối cảnh của đồ án 3, Nachos cung cấp một nền tảng cơ bản, nơi sinh viên phải tự mình xây dựng logic để nạp nhiều chương trình vào bộ nhớ, quản lý trạng thái của chúng và chuyển đổi ngữ cảnh giữa các tiến trình một cách an toàn. Đây là một bài tập thực hành quý giá, kết nối lý thuyết trên giảng đường với ứng dụng thực tế.

1.2. Mục tiêu chính của báo cáo môn hệ điều hành

Mục tiêu cốt lõi của báo cáo môn hệ điều hành này là trình bày quá trình và kết quả của việc nâng cấp Nachos để hỗ trợ đa chương. Cụ thể, các mục tiêu bao gồm: 1) Thiết kế và triển khai các cấu trúc dữ liệu để quản lý nhiều tiến trình, điển hình là lớp PTable và PCB (Process Control Block). 2) Cài đặt thành công các lời gọi hệ thống Exec, Join, và Exit để điều khiển vòng đời của tiến trình. 3) Sử dụng các cơ chế đồng bộ hóa tiến trình, chủ yếu là Semaphore, để giải quyết vấn đề chờ đợi giữa tiến trình cha và tiến trình con. 4) Quản lý cấp phát không gian địa chỉ và các trang bộ nhớ vật lý cho nhiều tiến trình. 5) Kiểm chứng hoạt động của hệ thống thông qua các chương trình thử nghiệm như Ping/Pong, chứng minh rằng các tiến trình có thể chạy xen kẽ và đồng bộ hóa đúng cách. Báo cáo này đóng vai trò là một tài liệu kỹ thuật, ghi lại các quyết định thiết kế và các chi tiết cài đặt quan trọng.

II. Thách thức quản lý và đồng bộ hóa tiến trình trong Nachos

Việc chuyển đổi từ hệ thống đơn chương sang đa chương trong hệ điều hành Nachos đặt ra nhiều thách thức kỹ thuật phức tạp, đòi hỏi một sự hiểu biết sâu sắc về các nguyên lý hoạt động của hệ điều hành. Thách thức lớn nhất là quản lý tiến trình trong Nachos. Hệ thống cần một cơ chế trung tâm để theo dõi tất cả các tiến trình đang hoạt động, đã kết thúc hoặc đang chờ. Điều này dẫn đến sự ra đời của PTable (Process Table), một cấu trúc dữ liệu quản lý một mảng các PCB (Process Control Block). Mỗi PCB chứa thông tin sống còn về một tiến trình, như ID tiến trình, trạng thái, và thông tin về tiến trình cha. Một thách thức khác là đồng bộ hóa tiến trình. Khi một tiến trình cha (parent) tạo ra một tiến trình con (child) bằng Exec, nó thường cần phải đợi cho tiến trình con hoàn thành công việc trước khi tiếp tục. Nếu không có cơ chế chờ đợi, tiến trình cha có thể kết thúc trước, gây ra các tiến trình "mồ côi" hoặc kết quả sai. Giải pháp cho vấn đề này là sử dụng semaphore trong Nachos. Tài liệu gốc đã sử dụng các semaphore joinsem và exitsem để quản lý trạng thái chờ và giải phóng của các tiến trình, đảm bảo sự phối hợp nhịp nhàng giữa chúng. Việc debug code Nachos trong môi trường đa luồng cũng là một thử thách lớn, vì các lỗi thường khó tái tạo và phụ thuộc vào thứ tự thực thi của các tiến trình.

2.1. Vấn đề đồng bộ hóa giữa tiến trình cha và con

Trong mô hình đa chương, mối quan hệ cha-con là nền tảng. System call Exec tạo ra tiến trình con, và Join cho phép tiến trình cha chờ con. Vấn đề phát sinh khi tiến trình cha gọi Join và phải bị khóa lại (blocked) cho đến khi tiến trình con thực thi xong và gọi Exit. Tài liệu nghiên cứu đã giải quyết vấn đề này bằng cách sử dụng hai semaphore trong mỗi PCB: joinsem và exitsem. Khi tiến trình cha gọi Join, nó sẽ thực hiện thao tác Wait() (hoặc P()) trên joinsem của tiến trình con, khiến nó bị đưa vào hàng đợi và nhường CPU. Khi tiến trình con kết thúc, nó sẽ gọi Exit, và bên trong Exit, nó thực hiện thao tác Signal() (hoặc V()) trên joinsem của tiến trình cha, đánh thức tiến trình cha dậy để tiếp tục công việc. Cơ chế này đảm bảo thứ tự thực thi chính xác và là một ví dụ điển hình về đồng bộ hóa tiến trình.

2.2. Khó khăn trong quản lý cấp phát tài nguyên hệ thống

Khi nhiều tiến trình cùng tồn tại, việc quản lý tài nguyên như bộ nhớ và ID tiến trình trở nên cấp thiết. Mỗi tiến trình cần một không gian địa chỉ riêng biệt và không được xâm phạm bộ nhớ của tiến trình khác. Thách thức ở đây là làm thế nào để cấp phát và thu hồi các trang bộ nhớ vật lý một cách hiệu quả. Tài liệu gốc đã sử dụng một đối tượng BitMap toàn cục tên là physicalPage để theo dõi trạng thái của từng trang nhớ vật lý (frame). Khi một tiến trình mới được tạo, hệ thống sẽ tìm các trang trống trong physicalPage bằng phương thức Find(), đánh dấu chúng là đã sử dụng và gán cho tiến trình mới. Tương tự, hệ thống cũng cần một cơ chế để quản lý các slot trong PTable. Một đối tượng BitMap khác, bm, được dùng trong lớp PTable để tìm một slot trống cho PCB mới. Việc quản lý tài nguyên này phải được bảo vệ bởi semaphore (addrLock) để tránh tình trạng hai tiến trình cùng được cấp phát một tài nguyên tại một thời điểm (race condition).

III. Phương pháp implement system call Nachos Exec và Join

Việc cài đặt các lời gọi hệ thống là trung tâm của đồ án hệ điều hành Nachos. Đây là giao diện chính cho phép các chương trình người dùng yêu cầu dịch vụ từ nhân hệ điều hành. Quá trình implement system call Nachos đòi hỏi sự hiểu biết về cả kiến trúc máy ảo MIPS và luồng xử lý ngoại lệ của Nachos. Báo cáo này tập trung vào hai system call khởi đầu cho quản lý tiến trình là Exec và Join. System call Exec chịu trách nhiệm tạo một tiến trình mới. Khi một chương trình người dùng gọi Exec, một trap (ngoại lệ) sẽ được tạo ra, chuyển quyền điều khiển từ user mode sang kernel mode. Tại đây, kernel sẽ đọc tên của file thực thi từ một thanh ghi, sao chép nó vào bộ nhớ kernel, sau đó tìm một slot trống trong PTable. Tiếp theo, kernel tạo một không gian địa chỉ mới (AddrSpace), nạp mã nguồn từ file thực thi vào không gian địa chỉ này, tạo một luồng (thread) mới để chạy tiến trình, và cuối cùng trả về ID của tiến trình mới cho chương trình gọi. Quá trình này liên quan mật thiết đến việc sử dụng MIPS cross-compiler để biên dịch chương trình người dùng và hiểu cách Nachos nạp chúng vào bộ nhớ. System call Join thực hiện chức năng đồng bộ hóa. Nó cho phép một tiến trình cha đợi một tiến trình con kết thúc. Khi được gọi, kernel sẽ xác định tiến trình cha và tiến trình con, sau đó sử dụng semaphore trong Nachos để khóa tiến trình cha lại. Tiến trình cha sẽ ở trạng thái chờ cho đến khi tiến trình con gọi Exit, giải phóng semaphore và cho phép tiến trình cha tiếp tục chạy.

3.1. Hướng dẫn cài đặt lời gọi hệ thống Exec chi tiết

Để cài đặt Exec, bước đầu tiên là đọc tên file chương trình từ bộ nhớ người dùng vào bộ nhớ kernel. Điều này được thực hiện bằng cách đọc địa chỉ chuỗi ký tự từ thanh ghi R4 và sao chép an toàn. Sau đó, gọi phương thức pTab->ExecUpdate(filename). Bên trong phương thức này, hệ thống sẽ dùng bitmap bm để tìm một vị trí trống (GetFreeSlot()) trong bảng tiến trình PTable. Nếu tìm thấy, một PCB mới sẽ được tạo, và ID của tiến trình cha (currentThread->processID) sẽ được lưu lại. Quan trọng nhất, một luồng kernel mới được tạo ra, và phương thức Fork được gọi để bắt đầu thực thi tiến trình mới này. Hàm Fork sẽ thiết lập stack cho luồng mới và đưa nó vào hàng đợi sẵn sàng. Cuối cùng, Exec trả về process ID của tiến trình mới được tạo ra qua thanh ghi R2. Nếu không thể tạo tiến trình (ví dụ, PTable đã đầy), nó sẽ trả về -1.

3.2. Cấu trúc và logic của lời gọi hệ thống Join

System call Join nhận vào một tham số là process ID của tiến trình con cần đợi. Kernel đọc ID này từ thanh ghi R4. Sau đó, nó gọi phương thức pTab->JoinUpdate(pID). Phương thức này trước hết kiểm tra xem tiến trình với pID có tồn tại và có phải là con của tiến trình hiện tại hay không. Nếu hợp lệ, tiến trình cha sẽ gọi phương thức JoinWait() trên PCB của chính nó. Bên trong JoinWait(), một semaphore (joinsem) sẽ được gọi Wait() (hay P()). Thao tác này sẽ khóa tiến trình cha lại, đưa nó vào trạng thái BLOCKED và nhường quyền sử dụng CPU cho một tiến trình khác trong hàng đợi READY. Tiến trình cha sẽ chỉ được "đánh thức" và tiếp tục chạy khi tiến trình con kết thúc và gọi JoinRelease() (bên trong ExitUpdate), vốn thực hiện thao tác Signal() (hay V()) trên chính joinsem đó. Join sẽ trả về mã thoát (exit code) của tiến trình con.

IV. Bí quyết cài đặt Exit và chỉnh sửa mã nguồn đồ án Nachos

System call Exit là mảnh ghép cuối cùng và quan trọng nhất trong bộ ba Exec-Join-Exit, đảm bảo vòng đời của một tiến trình được kết thúc một cách trọn vẹn. Nếu không có Exit, khi một tiến trình con hoàn thành, Nachos có thể hiểu lầm rằng toàn bộ hệ thống đã xong việc và dừng lại, trong khi tiến trình cha vẫn đang trong trạng thái chờ. Do đó, lời gọi hệ thống Exit không chỉ đơn thuần là kết thúc một tiến trình, mà còn là cơ chế thông báo cho tiến trình cha rằng nó đã hoàn thành. Khi một tiến trình gọi Exit, nó truyền vào một mã thoát (exit code). Kernel nhận mã này, lưu nó vào PCB của tiến trình hiện tại. Sau đó, nó thực hiện hành động quan trọng nhất: gọi phương thức ExitRelease() trên PCB của tiến trình cha. Hành động này sẽ Signal (giải phóng) joinsem, đánh thức tiến trình cha đang bị khóa bởi Join. Ngoài việc cài đặt system call mới, việc chỉnh sửa source code nachos hiện có cũng rất cần thiết. Ví dụ, constructor của lớp AddrSpace cần được sửa đổi để nhận tên file thay vì một đối tượng OpenFile, đồng thời kiểm tra xem có đủ trang nhớ vật lý trống (physicalPage->NumClear()) trước khi cấp phát. Việc thêm các biến toàn cục như pTab (quản lý tiến trình) và physicalPage (quản lý bộ nhớ) trong system.cc là nền tảng cho toàn bộ cơ chế đa chương.

4.1. Vai trò và cách cài đặt lời gọi hệ thống Exit

Vai trò của Exit là dọn dẹp tài nguyên và thông báo cho tiến trình cha. Khi Exit được gọi, kernel thực hiện các bước sau: 1) Đọc mã thoát từ thanh ghi R4. 2) Gọi phương thức pTab->ExitUpdate(exitCode). 3) Trong ExitUpdate, mã thoát được lưu vào PCB. 4) Hệ thống giải phóng tiến trình cha đang chờ bằng cách gọi pcb[parentID]->JoinRelease(), thao tác này sẽ Signal() vào joinsem của tiến trình cha. 5) Cuối cùng, tiến trình con giải phóng không gian địa chỉ của nó và luồng kernel tương ứng được đưa vào trạng thái kết thúc (sử dụng currentThread->Finish()). Việc dọn dẹp này đảm bảo tài nguyên (bộ nhớ, slot trong PTable) được trả lại cho hệ thống để tái sử dụng.

4.2. Các thay đổi quan trọng trong mã nguồn đồ án Nachos

Bên cạnh việc viết các system call mới, mã nguồn đồ án nachos cần được điều chỉnh ở nhiều nơi. Đầu tiên, các biến toàn cục PTable* pTab, BitMap* physicalPage, và Semaphore* addrLock được khai báo và khởi tạo trong system.h và system.cc. Thứ hai, constructor AddrSpace::AddrSpace được sửa để nhận char* filename, kiểm tra số trang trống (NumClear()) và sử dụng physicalPage->Find() để cấp phát từng trang nhớ vật lý thay vì cấp phát tuần tự. Thứ ba, phương thức ExecUpdate trong PTable được cập nhật để lưu parentID. Cuối cùng, một phương thức tĩnh ThreadFinish() được thêm vào để dọn dẹp currentThread sau khi một tiến trình kết thúc, tránh rò rỉ bộ nhớ. Những thay đổi này là xương sống giúp các system call hoạt động chính xác.

V. Hướng dẫn chạy và kiểm thử đồ án Nachos với Ping Pong

Kiểm thử là bước không thể thiếu để xác minh tính đúng đắn của việc triển khai đa chương trong đồ án Nachos. Một kịch bản kiểm thử kinh điển là sử dụng chương trình scheduler để khởi chạy đồng thời hai chương trình ping và pong. Chương trình ping sẽ in ra ký tự 'A' lặp đi lặp lại, trong khi pong in ra ký tự 'B'. Bằng cách quan sát kết quả đầu ra, có thể đánh giá được liệu cơ chế lập lịch CPU và chuyển đổi ngữ cảnh của Nachos có hoạt động đúng hay không. Hướng dẫn cài đặt Nachos và chạy thử nghiệm khá đơn giản. Sau khi biên dịch toàn bộ source code bằng lệnh make trong thư mục code, người dùng có thể chạy chương trình scheduler từ thư mục userprog. Lệnh thực thi thường có dạng ./nachos -x ../test/scheduler. Chương trình scheduler sẽ sử dụng system call Exec để tạo ra hai tiến trình con, một cho ping và một cho pong. Sau đó, nó sẽ gọi Join hai lần để chờ cả hai tiến trình con này kết thúc. Nếu cài đặt thành công, kết quả trên console sẽ là một chuỗi các ký tự 'A' và 'B' xen kẽ nhau, cho thấy CPU đã được luân chuyển giữa hai tiến trình. Cuối cùng, sau khi cả hai tiến trình kết thúc, dòng chữ "Finish Ping-Pong test" từ scheduler sẽ được in ra, chứng tỏ Join đã hoạt động chính xác.

5.1. Thiết lập kịch bản kiểm thử với chương trình scheduler

Chương trình scheduler.c đóng vai trò là tiến trình cha. Mã nguồn của nó rất đơn giản: đầu tiên, nó in ra một thông báo bắt đầu. Sau đó, nó gọi Exec("../test/ping") và Exec("../test/pong"), lưu lại hai process ID trả về. Tiếp theo, nó gọi Join() với ID của tiến trình ping và Join() với ID của tiến trình pong. Lời gọi Join đầu tiên sẽ khiến scheduler bị khóa cho đến khi ping kết thúc. Sau khi ping kết thúc, Join trả về, và scheduler tiếp tục gọi Join thứ hai, chờ pong. Chỉ khi cả hai tiến trình con đã hoàn thành, scheduler mới tiếp tục thực thi và in ra thông báo kết thúc. Kịch bản này kiểm tra toàn diện cả ba system call: Exec tạo tiến trình, và Join/Exit đảm bảo sự đồng bộ hóa.

5.2. Phân tích kết quả và ý nghĩa của việc chạy đa chương

Kết quả đầu ra thành công có hai đặc điểm chính. Thứ nhất, chuỗi ký tự 'A' và 'B' xen kẽ (ví dụ: AABABB...) chứng tỏ rằng bộ lập lịch của Nachos đang hoạt động. Nó cấp phát các lát cắt thời gian (time slice) cho cả hai tiến trình, thực hiện chuyển đổi ngữ cảnh giữa chúng. Thứ hai, và quan trọng không kém, là sự xuất hiện của dòng chữ "Finish Ping-Pong test" sau khi tất cả các ký tự 'A' và 'B' đã được in. Điều này là bằng chứng đanh thép rằng system call Join đã hoạt động đúng, buộc tiến trình scheduler (cha) phải chờ đợi các tiến trình con của nó. Nếu không có Join hoặc Join cài đặt sai, scheduler có thể đã kết thúc và in ra thông báo này ngay từ đầu, hoặc Nachos sẽ dừng lại ngay khi ping hoặc pong kết thúc. Việc này khẳng định hệ thống đã có khả năng mô phỏng hệ điều hành đa chương.

VI. Tổng kết đồ án Nachos Bách Khoa và các tài liệu tham khảo

Việc hoàn thành đồ án 3 Nachos là một thành tựu đáng kể, đánh dấu sự nắm vững các khái niệm nền tảng về hệ điều hành của sinh viên. Báo cáo này đã trình bày một cách có hệ thống quá trình triển khai tính năng đa chương, từ việc phân tích các thách thức, thiết kế giải pháp, cài đặt các lời gọi hệ thống quan trọng, đến việc kiểm thử và xác minh kết quả. Những kinh nghiệm rút ra từ đồ án này, đặc biệt là các dự án tương tự đồ án Nachos Bách Khoa, có giá trị thực tiễn cao, giúp sinh viên chuẩn bị cho các vấn đề phức tạp trong ngành công nghiệp phần mềm. Các kỹ năng như làm việc với mã nguồn lớn, debug code Nachos trong môi trường đa luồng, và thiết kế các cơ chế đồng bộ hóa là vô cùng quý báu. Thông qua việc cài đặt Exec, Join và Exit, sinh viên không chỉ học được cách một hệ điều hành quản lý tiến trình, mà còn hiểu được "cái giá" của việc chuyển đổi ngữ cảnh và sự cần thiết của các cơ chế bảo vệ tài nguyên. Đây là một báo cáo môn hệ điều hành hoàn chỉnh, thể hiện sự thành công trong việc áp dụng lý thuyết vào thực tiễn. Nguồn tài liệu Nachos tiếng Việt như thế này sẽ là tài liệu tham khảo hữu ích cho các khóa sau, giúp họ có một khởi đầu thuận lợi hơn.

6.1. Những điều đã đạt được và bài học kinh nghiệm

Kết quả chính của đồ án là đã cài đặt thành công ba system call Exec, Join, Exit và các cấu trúc dữ liệu hỗ trợ (PTable, PCB). Hệ thống Nachos đã có thể chạy nhiều chương trình đồng thời, đồng bộ hóa giữa chúng và quản lý tài nguyên bộ nhớ một cách cơ bản. Bài học kinh nghiệm lớn nhất là tầm quan trọng của việc thiết kế cẩn thận trước khi viết code. Việc hiểu rõ luồng hoạt động của các semaphore và cách chúng giải quyết vấn đề chờ đợi là chìa khóa thành công. Ngoài ra, việc đọc và hiểu source code Nachos có sẵn là một kỹ năng quan trọng, giúp tận dụng lại các lớp đã được xây dựng như BitMap và Thread một cách hiệu quả.

6.2. Hướng phát triển và nâng cấp trong tương lai

Mặc dù đã hoàn thành các yêu cầu cơ bản, hệ thống vẫn có thể được cải tiến thêm. Một hướng phát triển tiềm năng là cài đặt các chiến lược lập lịch CPU phức tạp hơn thay vì Round-Robin mặc định, ví dụ như ưu tiên (Priority Scheduling) hoặc SJF (Shortest Job First). Một hướng khác là mở rộng quản lý bộ nhớ với cơ chế bộ nhớ ảo (virtual memory) và swapping, cho phép chạy các chương trình lớn hơn kích thước bộ nhớ vật lý. Ngoài ra, có thể triển khai thêm các system call khác như CreateSemaphore, Up, Down để cung cấp cơ chế đồng bộ hóa mạnh mẽ hơn cho các chương trình người dùng, thay vì chỉ giới hạn ở cấp độ kernel. Những cải tiến này sẽ đưa Nachos tiến gần hơn đến một hệ điều hành hiện đại và đa năng.

Nội dung chính

Bối cảnh và vấn đề nghiên cứu

Báo cáo kỹ thuật "Báo cáo Đồ án 3 - Nachos" được thực hiện trong khuôn khổ môn học Hệ điều hành (Học kỳ I, năm học 2021 – 2022) tại Trường Đại học Khoa học Tự nhiên – Đại học Quốc gia Thành phố Hồ Chí Minh, dưới sự hướng dẫn của giảng viên Lê Viết Long. Nhóm sinh viên thực hiện gồm ba thành viên: Bùi Phước Thiện (MSSV: 21127168), Phan Lâm Anh (MSSV: 21127580) và Quách Tấn Dũng (MSSV: 21127247). Văn bản hoàn thiện vào tháng 4 năm 2024.

Trong cấu trúc nguyên bản của hệ điều hành mô phỏng Nachos (phiên bản Nachos 3.4), môi trường thực thi được thiết kế ở trạng thái đơn chương, thiếu hụt các cơ chế quản lý vòng đời tiến trình, không gian địa chỉ động và cơ chế đồng bộ hóa giữa các luồng thực thi độc lập. Khi một tiến trình người dùng được nạp vào bộ nhớ, hệ thống chưa hỗ trợ các giao diện lập trình cấp hệ thống để tạo mới, chờ đợi hoặc kết thúc tiến trình một cách an toàn. Thực trạng này dẫn đến việc hệ thống tự động chấm dứt toàn bộ phiên làm việc ngay khi một luồng con kết thúc hoặc không thể điều phối nhiều chương trình cùng vận hành đồng thời.

Mục tiêu và nhiệm vụ nghiên cứu của đồ án được xác định cụ thể như sau:

1. Nghiên cứu mô hình quản lý tiến trình, cơ chế đồng bộ hóa và các cấu trúc dữ liệu nền tảng trong hệ điều hành Nachos 3.4 (PTable, PCB, BitMap, Thread).
2. Thiết kế và cài đặt ba lời gọi hệ thống (system call) cốt lõi phục vụ cơ chế đa chương: Exec (khởi tạo và thực thi tiến trình), Join (tiến trình cha chờ tiến trình con hoàn tất) và Exit (chấm dứt tiến trình con, trả mã thoát và nhường quyền điều khiển).
3. Hiệu chỉnh mã nguồn hạt nhân của Nachos trong các tệp tin hệ thống (system.cc, system.h, addrspace.cc, addrspace.h, thread.cc, thread.h) nhằm hỗ trợ cấp phát bộ nhớ trang vật lý không liên tục và quản lý tiến trình cha - con.
4. Cấu hình lại các thông số phần cứng mô phỏng (NumPhysPages, SectorSize) và kiểm thử tính đúng đắn của giải pháp thông qua chương trình điều phối scheduler chạy đồng thời hai tiến trình Ping và Pong.

Đối tượng nghiên cứu là nhân hệ điều hành mô phỏng Nachos 3.4 viết bằng ngôn ngữ C++, tập trung vào phân hệ quản lý tiến trình (userprog) và quản lý bộ nhớ. Phạm vi không gian nghiên cứu giới hạn trong môi trường giả lập máy ảo MIPS của Nachos. Phạm vi thời gian và phân công công việc kỹ thuật được ghi nhận: Bùi Phước Thiện chịu trách nhiệm cài đặt system call Exec và CreateSemaphore; Phan Lâm Anh chịu trách nhiệm cài đặt system call Join, Up và biên soạn báo cáo; Quách Tấn Dũng chịu trách nhiệm cài đặt system call Exit, Down và biên soạn báo cáo. Tỷ lệ hoàn thành công việc của cả ba thành viên đạt 100%.

Cơ sở lý thuyết và phương pháp

Nghiên cứu dựa trên nền tảng lý thuyết về hệ điều hành đa chương, mô hình tiến trình phân cấp (Parent - Child Process Model), không gian địa chỉ ảo và cơ chế đồng bộ hóa luồng thông qua Semaphore:

• Mô hình quản lý tiến trình và đồng bộ hóa: Hoạt động phối hợp giữa luồng cha và luồng con dựa trên các nguyên lý đồng bộ hóa. Khi tiến trình cha gọi Exec, một luồng mới được tạo lập và biến đếm số lượng luồng con tăng lên. Khi gọi Join, tiến trình cha rơi vào trạng thái chờ (JoinWait(), sử dụng cơ chế Semaphore để chặn) cho đến khi tiến trình con kết thúc và phát tín hiệu giải phóng (JoinRelease()). Khi tiến trình kết thúc thông qua Exit, nó phải đợi tất cả các tiến trình con của chính nó hoàn tất thông qua ExitWait() trước khi gọi ExitRelease() để báo hiệu cho tiến trình cha.
• Cơ chế chuyển đổi không gian nhớ và thanh ghi MIPS: Nachos mô phỏng kiến trúc phần cứng MIPS. Việc trao đổi dữ liệu giữa không gian người dùng (User Space) và không gian hạt nhân (System/Kernel Space) được thực hiện thông qua các thanh ghi máy ảo: thanh ghi R4 dùng để truyền tham số đầu vào (địa chỉ vùng nhớ, mã tiến trình hoặc mã thoát) và thanh ghi R2 dùng để chứa giá trị trả về của lời gọi hệ thống. Biến đếm chương trình (Program Counter) được điều chỉnh tăng sau mỗi system call để tránh hiện tượng lặp lệnh vô hạn.

Phương pháp nghiên cứu thực tế bao gồm:

• Phương pháp phân tích và can thiệp mã nguồn: Khảo sát các lớp đối tượng có sẵn trong hệ thống Nachos, xác định các điểm bất đồng bộ trong constructor của lớp AddrSpace và tiến hành tái cấu trúc logic nạp dữ liệu từ tệp thực thi vào bộ nhớ chính.
• Phương pháp kỹ thuật hệ thống (System Implementation): Khai báo các đối tượng quản lý toàn cục, bổ sung phương thức hỗ trợ dọn dẹp tài nguyên luồng (ThreadFinish()), tái sử dụng phương thức tìm kiếm vị trí bit trống của BitMap để quản lý khung trang vật lý và bảng tiến trình.
• Phương pháp thực nghiệm kiểm thử: Xây dựng tệp mã nguồn người dùng scheduler.c kết hợp cùng ping.c và pong.c. Sử dụng cờ chuyển ngữ cảnh ngẫu nhiên -rs 1023 và cờ thực thi -x để kiểm tra khả năng chia sẻ thời gian của CPU giữa các tiến trình độc lập.

Nguồn dữ liệu kỹ thuật và tài liệu tham khảo được sử dụng gồm tài liệu hướng dẫn do giảng viên cung cấp ("Các Lớp Trong Project 3.docx", "DoAn3 CQ 2021.docx", "Cach Viet Mot SystemCall.pdf", "Seminar HDH_Project 3.pptx"), tài liệu lưu trữ hướng dẫn thực hành Nachos của Đại học Duke (CPS 110 Nachos Guide) và tài liệu kỹ thuật từ hệ thống Mystudy HCMUS.

Thiết kế và triển khai

Hệ thống được thiết kế dựa trên sự phối hợp của bốn cấu trúc dữ liệu chính trong Nachos, chịu trách nhiệm quản lý bảng tiến trình, khối điều khiển tiến trình, bộ nhớ bit và luồng thực thi.

Tên lớp / Cấu trúc	Thuộc tính chính	Phương thức chính	Vai trò kỹ thuật
PTable	MAXPROCESS (hằng số = 10), BitMap* bm, PCB* pcb[MAXPROCESS], int psize, Semaphore* bmsem	PTable(int size), ExecUpdate(char* filename), ExitUpdate(int ec), JoinUpdate(int pID), GetFreeSlot(), IsExist(int pID), Remove(int pID), GetName(int pID)	Quản lý toàn bộ các tiến trình trong hệ thống. Một thể hiện duy nhất pTab được khởi tạo toàn cục tại system.cc.
PCB	Semaphore* joinsem, Semaphore* exitsem, Semaphore* mutex, int exitCode, Thread* thread, int pid, int numwait, int parentID, int joinstatus	PCB(int id), Exec(char* filename, int pID), GetID(), GetNumWait(), JoinWait(), ExitWait(), JoinRelease(), ExitRelease(), IncNumWait(), DecNumWait(), SetExitCode(int ec), GetExitCode(), GetNameThread()	Khối điều khiển tiến trình (Process Control Block), lưu trữ trạng thái vòng đời, quan hệ cha - con và điều phối đồng bộ hóa cho từng tiến trình.
BitMap	BitsInByte, BitsInWord, int numBits, int numWords, unsigned int* map	BitMap(int nitems), Mark(int which), Clear(int which), Test(int which), Find(), NumClear(), Print(), FetchFrom(OpenFile* file), WriteBack(OpenFile* file)	Quản lý cấp phát và giải phóng tài nguyên dạng mảng bit. Dùng để quản lý khe tiến trình rỗng trong PTable và khung trang trong physicalPage.
Thread	MachineStateSize, StackSize, ThreadStatus status, int* stackTop, int machineState[], int processID, int* stack, char* name, int userRegisters[], AddrSpace* space	Thread(char* threadName), Fork(), Yield(), Sleep(), Finish(), CheckOverflow(), setStatus(), ThreadFinish() (nhóm bổ sung), SaveUserState(), RestoreUserState()	Quản lý ngữ cảnh thực thi CPU, ngăn xếp (stack), trạng thái luồng (JUST_CREATED, RUNNING, READY, BLOCKED) và vùng nhớ người dùng.

Quy trình hoạt động kỹ thuật của ba lời gọi hệ thống được cài đặt:

• Cài đặt System Call Exec: Nhận địa chỉ vùng nhớ chứa tên tệp chương trình từ thanh ghi R4. Đọc chuỗi tên với độ dài MAX_BUFFER_LENGTH + 1 (tương đương 255 byte) và chuyển đổi từ User Space sang System Space. Nếu việc đọc tên thất bại, hệ thống ghi giá trị -1 vào thanh ghi R2 và thoát. Nếu thành công, gọi phương thức pTab->ExecUpdate(filename) để tiến hành khởi chạy tiến trình, lưu mã định danh tiến trình nhận được vào biến pid, sau đó ghi pid vào thanh ghi R2 và tăng biến đếm Program Counter.
• Cài đặt System Call Join: Đọc mã định danh tiến trình con cần chờ từ thanh ghi R4 và gán vào biến pid. Chuyển pid vào phương thức pTab->JoinUpdate(pid). Phương thức này chặn tiến trình cha cho đến khi tiến trình con hoàn tất và trả về mã thoát exitCode. Kết quả được ghi vào thanh ghi R2 trước khi tăng Program Counter để tiếp tục lệnh kế tiếp.
• Cài đặt System Call Exit: Đọc giá trị mã thoát từ thanh ghi R4 và gán vào biến joinExitCode. Nếu xảy ra lỗi từ phía Join (mã khác 0), chương trình tăng Program Counter và kết thúc. Trường hợp không có lỗi, giá trị này được nạp vào phương thức pTab->ExitUpdate(joinExitCode). Sau đó, hệ thống thực hiện giải phóng tài nguyên cho con trỏ luồng hiện hành currentThread bằng cách gọi phương thức tĩnh ThreadFinish(), tăng Program Counter và kết thúc.

Các hiệu chỉnh bổ sung trong mã nguồn hệ thống:

1. Khai báo biến toàn cục mới tại vùng #USER_PROGRAM trong system.cc:
   • Semaphore* addrLock: Semaphore khởi tạo với giá trị ban đầu bằng 1, bảo đảm truy xuất độc quyền vào các thao tác của lớp AddrSpace.
   • PTable* pTab: Khởi tạo đối tượng bảng tiến trình với khả năng quản lý tối đa 10 tiến trình (MAXPROCESS = 10).
   • BitMap* physicalPage: Khởi tạo với kích thước 256 bit, chịu trách nhiệm quản lý việc cấp phát các khung trang bộ nhớ vật lý.
2. Hiệu chỉnh phương thức GetFreeSlot() và ExecUpdate(): Tận dụng phương thức Find() của lớp BitMap để tìm vị trí trống và tự động đánh dấu, loại bỏ lệnh bm->Mark(ID) bị dư thừa trong ExecUpdate(). Bổ sung lệnh gán quan hệ cha - con: pcb[ID]->parentID = currentThread->processID.
3. Hiệu chỉnh phương thức ExitUpdate(): Bỏ qua điều kiện kiểm tra tiến trình cha như phiên bản mã nguồn cũ nhằm đảm bảo tiến trình luôn thực hiện giải phóng Join để tránh việc Nachos dừng đột ngột khi tiến trình cha chưa hoàn tất.
4. Tái cấu trúc constructor AddrSpace: Thay đổi chữ ký phương thức từ AddrSpace::AddrSpace(OpenFile* executable) sang AddrSpace::AddrSpace(char* filename). Đặt đoạn mã khởi tạo giữa cặp lệnh khóa addrLock->P() và addrLock->V(). Kiểm tra điều kiện số trang yêu cầu numPages không vượt quá số trang vật lý còn trống (physicalPage->NumClear()). Thay thế cơ chế gán trang vật lý tuần tự pageTable[i].physicalPage = i bằng phương thức cấp phát động physicalPage->Find(). Cập nhật lại logic chuyển phân đoạn dữ liệu tệp NOFF vào bộ nhớ chính machine->mainMemory. Gán định danh tiến trình thread->processID = currentThread->processID trong phương thức Exec().
5. Bổ sung phương thức tĩnh Thread::ThreadFinish(): Thực hiện giải phóng không gian địa chỉ space của biến toàn cục currentThread và yêu cầu luồng dừng thực thi.
6. Cập nhật hằng số phần cứng giả lập: Nâng giá trị hằng số NumPhysPages từ giá trị cũ lên 128 trang vật lý; điều chỉnh giá trị hằng số SectorSize lên 512 byte.

Nội dung chính theo từng chương

Thông tin nhóm và công việc phân công

Báo cáo liệt kê chi tiết cơ cấu thành viên nhóm và bảng phân bổ công việc. Cả ba thành viên đều đảm nhận khối lượng công việc cụ thể liên quan trực tiếp đến việc phát triển mã nguồn của các system call (Exec, CreateSemaphore, Join, Up, Exit, Down) và viết báo cáo, đạt mức độ hoàn thành 100%.

Mô hình quản lý tiến trình

Nội dung chương mô tả luồng điều phối của ba thao tác cơ bản trong hệ điều hành đa chương:

• Hoạt động Exec: Luồng cha kích hoạt luồng con, tăng biến đếm quản lý luồng trong lớp luồng cha.
• Hoạt động Join: Luồng cha rơi vào trạng thái chờ đợi thông qua JoinWait() (bản chất sử dụng cơ chế Semaphore). Khi luồng con thực thi xong, nó phát tín hiệu JoinRelease() để đánh thức luồng cha tiếp tục hoạt động.
• Hoạt động Exit: Khi một luồng hoàn tất công việc, nó bắt buộc phải chờ toàn bộ các luồng con kết thúc thông qua ExitWait(). Khi các luồng con đã hoàn tất, luồng này gọi ExitRelease() để cho phép luồng cha tiếp tục. Điểm lưu ý quan trọng là nếu hệ thống chỉ dùng Join mà không có Exit, Nachos sẽ dừng ngay lập tức khi luồng con đầu tiên kết thúc.

Các lớp cần tìm hiểu

Chương này hệ thống hóa toàn bộ thông tin kiến trúc của bốn lớp đối tượng quan trọng trong mã nguồn Nachos bao gồm: PTable, PCB, BitMap và Thread. Từng lớp được mô tả chi tiết dưới dạng bảng liệt kê tên thuộc tính, hằng số, kiểu dữ liệu, chức năng và nguồn gốc cung cấp từ phía giảng viên. Đây là nền tảng kỹ thuật để nhóm tiến hành chỉnh sửa và viết thêm mã nguồn.

Các system call mà nhóm cần cài đặt thêm vào

Phần này trình bày giải thuật chi tiết và mã giả của ba system call: Exec, Join và Exit. Nội dung giải thích rõ ràng cơ chế tương tác với các thanh ghi MIPS giả lập (R2, R4), quy trình chuyển đổi dữ liệu giữa bộ nhớ người dùng và hệ thống, cách thức gọi các phương thức tương ứng của biến toàn cục pTab (ExecUpdate, JoinUpdate, ExitUpdate) và thao tác cập nhật thanh ghi Program Counter để kết thúc system call.

Các chỉnh sửa đã thực hiện ở source code

Tài liệu ghi lại toàn bộ các can thiệp thực tế trên mã nguồn C++ của hệ thống Nachos:

• Khai báo và khởi tạo 3 biến toàn cục mới trong system.cc (addrLock, pTab, physicalPage).
• Điều chỉnh logic cấp phát trong GetFreeSlot(), tối ưu hóa ExecUpdate() và sửa đổi luồng kết thúc trong ExitUpdate().
• Sửa đổi constructor của AddrSpace để hỗ trợ nạp tệp trực tiếp theo tên, đồng bộ hóa bằng Semaphore và phân phối trang nhớ vật lý động thông qua BitMap.
• Cập nhật phương thức MyStartProcess(int pID), bổ sung hàm tĩnh ThreadFinish() dọn dẹp bộ nhớ và tăng kích thước phần cứng giả lập (NumPhysPages = 128, SectorSize = 512).

Chạy thử chương trình Scheduler

Chương này trình bày kịch bản thực nghiệm nhằm chứng minh hệ thống đã hỗ trợ đa chương thành công:

• Tái cấu trúc chương trình scheduler.c sử dụng system call Join để chờ cả hai tiến trình Ping và Pong chạy xong, in ra chuỗi thông báo kết thúc "Finish Ping-Pong test".
• Giữ nguyên cấu trúc của chương trình Ping và Pong theo yêu cầu đề bài.
• Cung cấp câu lệnh thực thi kiểm thử và trích xuất nguyên văn nhật ký xuất ra từ màn hình console máy ảo.

Tổng kết và hướng dẫn sử dụng

Tổng kết các hạng mục đã hoàn thành, ghi nhận tình trạng thực hiện và cung cấp tài liệu hướng dẫn từng bước từ việc biên dịch mã nguồn bằng lệnh make đến câu lệnh khởi chạy chương trình kiểm thử trên console.

Kết quả và đóng góp

Đồ án ghi nhận kết quả thực nghiệm hoàn chỉnh thông qua việc biên dịch và chạy kịch bản kiểm thử đa chương với lệnh:

../userprog/nachos -rs 1023 -x ./test/scheduler

Kết quả hiển thị trên màn hình console cho thấy hai tiến trình Ping (in ký tự A) và Pong (in ký tự B) được CPU lập lịch luân phiên xuất hiện xen kẽ nhau liên tục. Trước khi hệ thống dừng lại, thông điệp kiểm thử hoàn tất đã xuất hiện chính xác:

Ping-Pong test starting.
AAAAAAAAABBBBBBBBBBBBBBAAAAAABBBBBBBAABBBAAABBBAABAABBBAAAAAABBAAAAAAAABBBBBAAAABAABBBABAABBBBBBBBABAABAABBB...
Finish Ping-Pong test
Machine halting!

Các thông số thống kê phần cứng máy ảo ghi nhận tại thời điểm kết thúc phiên thực thi:

Thông số hoạt động hệ thống	Giá trị ghi nhận
Tổng số nhịp đồng hồ (Ticks: total)	297,750
Nhịp trạng thái rảnh (Ticks: idle)	195,607
Nhịp thực thi hệ thống (Ticks: system)	70,030
Nhịp người dùng thực thi (Ticks: user)	32,113
Thao tác đĩa (Disk I/O: reads / writes)	0 / 0
Thao tác màn hình Console (Console I/O: reads / writes)	0 / 2,053
Lỗi trang bộ nhớ (Paging: faults)	0
Giao tiếp mạng (Network I/O: packets received / sent)	0 / 0

Đóng góp kỹ thuật của đồ án bao gồm:

• Hoàn thành đầy đủ bộ ba system call cơ bản quản lý đa chương (Exec, Join, Exit), cho phép Nachos thực thi các chương trình người dùng độc lập.
• Chuyển đổi thành công cơ chế quản lý bộ nhớ của Nachos từ cấp phát tĩnh liên tục sang cấp phát động theo từng khung trang vật lý dựa trên cấu trúc BitMap, giải quyết tình trạng xung đột không gian nhớ giữa các tiến trình khi chạy đa chương.
• Đảm bảo an toàn luồng và đồng bộ hóa tiến trình thông qua việc tích hợp Semaphore (addrLock, joinsem, exitsem, bmsem) vào cấu trúc AddrSpace và PTable.

Hạn chế và hướng nghiên cứu tiếp

Trong văn bản báo cáo, phần "Những điều chưa làm được" được nhóm tác giả để trống nội dung. Tuy nhiên, căn cứ vào giới hạn cấu hình và phạm vi triển khai thực tế được trình bày trong tài liệu:

• Hạn chế kỹ thuật: Số lượng tiến trình đa chương tối đa bị giới hạn cố định ở mức 10 tiến trình (MAXPROCESS = 10). Bộ nhớ vật lý được nâng lên 128 khung trang (NumPhysPages = 128), hệ thống chưa cài đặt cơ chế bộ nhớ ảo mở rộng (swap file/backing store) ra đĩa từ khi bộ nhớ đầy (thống kê Disk I/O ghi nhận 0 lượt đọc/ghi và Paging faults ghi nhận 0). Cơ chế phân phối trang chỉ dừng ở mức tìm kiếm vị trí bit trống đầu tiên (Find()).
• Hướng nghiên cứu tiếp theo: Nâng cấp khả năng quản lý danh sách tiến trình động thay vì mảng tĩnh giới hạn bởi MAXPROCESS; nghiên cứu và hiện thực các giải thuật thay thế trang (Page Replacement Algorithms như FIFO, LRU) khi số lượng trang yêu cầu vượt quá dung lượng 128 khung trang vật lý có sẵn.

Giá trị tham khảo

Báo cáo là tài liệu tham khảo trực tiếp cho sinh viên ngành Khoa học Máy tính, Kỹ thuật Phần mềm và Công nghệ Thông tin đang theo học học phần Hệ điều hành hoặc các môn học có thực hành trên mã nguồn Nachos.

Các phần nội dung có giá trị tham khảo chuyên sâu gồm:

• Quy trình chuẩn hóa thao tác đọc dữ liệu chuỗi từ User Space vào Kernel Space thông qua thanh ghi MIPS trong system call Exec.
• Kỹ thuật tái cấu trúc constructor AddrSpace để nạp tệp chương trình và cấp phát bộ nhớ động không liên tục thông qua BitMap::Find().
• Phương pháp phối hợp giữa JoinWait(), JoinRelease(), ExitWait() và ExitRelease() để kiểm soát tiến trình cha - con, ngăn ngừa việc hệ điều hành bị sập sớm khi có tiến trình hoàn tất trước.

Câu hỏi thường gặp

1. Vì sao nhóm tác giả phải thay đổi constructor của lớp AddrSpace từ nhận con trỏ OpenFile* sang nhận chuỗi char* filename?
Nhóm tác giả thay đổi cấu trúc này do phát hiện sự bất đồng bộ trong cách gọi constructor ở đoạn mã nguồn có sẵn được cung cấp. Việc nhận trực tiếp tên tệp (char* filename) cho phép hàm tự quản lý việc mở tệp, đồng thời cho phép bao bọc toàn bộ logic kiểm tra dung lượng trang trống (NumClear()) và cấp phát khung trang vật lý động giữa cặp khóa đồng bộ addrLock->P() và addrLock->V().

2. Lời gọi hệ thống Exec trao đổi tham số và trả kết quả cho tiến trình thông qua các thanh ghi nào?
Tham số đầu vào là con trỏ mảng ký tự chứa tên tiến trình được đọc từ thanh ghi R4 với kích thước giới hạn MAX_BUFFER_LENGTH + 1 (255 byte). Kết quả thực thi là mã định danh tiến trình (pid) hoặc mã lỗi -1 (khi không đọc được tên tiến trình) được ghi trực tiếp vào thanh ghi R2 trước khi trả quyền điều khiển về cho người dùng.

3. Tại sao trong phương thức ExitUpdate(int ec), nhóm tác giả lại lược bỏ đoạn mã kiểm tra tiến trình cha như mã nguồn cũ?
Theo phân tích của nhóm, phương thức ExitUpdate chỉ được kích hoạt từ lời gọi hệ thống Exit. Để Exit có thể chạy, điều kiện tiên quyết là phải có một tiến trình nào đó đã được Join. Do đó, việc kiểm tra tiến trình cha là không cần thiết. Nếu không thực hiện thao tác giải phóng tiến trình tại bước này, Nachos sẽ lập tức ngừng hoạt động trong khi tiến trình cha vẫn chưa hoàn thành công việc.

4. Mục đích của việc viết lại chương trình kiểm thử scheduler.c và bổ sung lệnh gọi Join là gì?
Nếu không sử dụng lệnh gọi hệ thống Join, khi một trong hai chương trình Ping hoặc Pong chạy xong trước, hệ thống Nachos sẽ hiểu lầm là toàn bộ công việc đã hoàn tất và dừng máy ảo ngay lập tức. Việc bổ sung Join bắt buộc tiến trình điều phối scheduler phải chờ cả hai tiến trình Ping và Pong kết thúc hoàn toàn rồi mới tiếp tục chạy đến lệnh in dòng chữ "Finish Ping-Pong test" trước khi hệ thống dừng lại.

5. Các thông số phần cứng của Nachos đã được nhóm điều chỉnh như thế nào và kết quả nhịp xung nhịp khi chạy kiểm thử đạt bao nhiêu?
Hằng số số lượng trang vật lý NumPhysPages được điều chỉnh thành 128 và kích thước sector đĩa SectorSize được đổi thành 512. Khi chạy kiểm thử với tham số -rs 1023, tổng số nhịp xung nhịp của máy ảo đạt 297,750 Ticks, bao gồm 195,607 nhịp rảnh (idle), 70,030 nhịp hệ thống (system) và 32,113 nhịp người dùng (user).

Kết luận

Đồ án "Báo cáo Đồ án 3 - Nachos" của nhóm sinh viên Trường Đại học Khoa học Tự nhiên – ĐHQG-HCM đã hiện thực hóa thành công cơ chế quản lý tiến trình đa chương trên hệ điều hành mô phỏng Nachos 3.4. Nghiên cứu đã hoàn thành việc cài đặt ba lời gọi hệ thống nòng cốt Exec, Join, Exit kết hợp cùng cơ chế đồng bộ hóa bằng Semaphore và cấp phát khung trang vật lý động thông qua cấu trúc BitMap. Kết quả kiểm thử thực nghiệm trên chương trình scheduler điều phối luân phiên hai tiến trình Ping và Pong chứng minh hệ thống vận hành ổn định, chính xác theo đúng các nguyên lý thiết kế của hệ điều hành.

Trích đoạn nội dung tài liệu

DAI HOC QUOC GIA TP. HỎ CHÍ MINH TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN UNIVERSITY OF SCIENCES c KHo, > vo An (©) cS Vain ay? @ = 3œ v ¬¬ TP. HO CHI MINH BAO CAO DO AN 3 - NACHOS Môn học: Hệ điều hành Hoc ky I (2021 — 2022) Sinh vién: Bui Phuoe Thién — 21127168 Phan Lam Anh — 21127580 Quach Tan Diing - 21127247 Truong: Dai hoc Khoa hoc Tu Nhién, DHQG - HCM Giáo viên: Thay Lé Viét Long Thành phó Hỗ Chí Minh, tháng 4 năm 2024 MỤC LỤC Thông tin nhóm và công việc phân CÔng. --- --- sọ gi ng ng re 4 Mô hình quản lý tiễn trình.

7 Cac lop 880i NNESh. 25 Các system call mà nhóm cần cài đặt thêm vào. 34 Các chỉnh sửa mà nhóm đã thực hiện 6 source COde. Khai báo các biến toàn cục mới ở system.

Phương thức GietFFreeSÌÏOf(). Phương thức ExecUpdate(char* filenain©). Phuong thitc ExitUpdate(int €C). 0Q Họ Họ HH Thư 39.

_ Phương thức Exec(char *filename, Inf pÏÏ).- s5 + sex sex se sex 42 b. Phương thức MyStartProcess(Inf pÏÏ). 9 ng mg 42 uc. _ Viết thêm phương thức tĩnh ThreadFinish() dé dọn rác cho currentThread.

_ Thay đôi giá trị hằng số NumPhysPages. 43 CN ốc ốc. 43 Chay thử chương trình SchecÌUÏ€T. nh ng ga 44 1.

Chương trình schedUÏeT. Chương trình Ping/Pong. Những điều đã làm được. Những điều chưa làm đượcC.-- ¿2 25+S+2E 2E 2 eEeEkerkerkerrkererererervee 47 Hướng dẫn sử dụng chương trình.-- - 2-6 55+ +x£Ex+E£YtEEEEEEEEEEkrtkrkrrkrrkrrrrrrrrree 48 IE 800i i84 0.

49 Thông tin nhóm và công việc phân công STT MSSV Ho va tén Công việc Tỉ lệ hoàn thành 01 21127168 Bùi Phước | - Việt system call Exec 100% Thiện - Viết system call CreateSemaphore 02 21127580 Phan Lâm _| - Viet system call Join 100% Anh - Viết báo cáo -Viét system call Up 03 21127247 Quách Tân | - Viét bao cáo 100% Dũng -Viết system call Exit -Viết system call Down Mô hình quản lý tiễn trình 1. Exec Trên thread cha, có một đoạn mã được sử dụng để khởi chạy các luồng con. Mỗi khi một luồng con được khởi chạy, một biến đêm trong lớp Thread cha sẽ tăng lên I đơn vi. Thread cha Thread con 2.

Join Khi một Thread cha Exec một Thread con, ta can Thread cha cho doi Thread con chay xong hết, rồi Thread cha mới tiếp tục chạy. Lúc này, Thread cha sẽ chờ bằng cách Join Wait (bên trong thực chất chỉ là Semaphore Up()), khi Thread con chay xong, Thread con sé thyc hién Join Release (bén trong thy chat la Semaphore Down()). Sau khi Thread con chạy xong, Thread cha sẽ ngưng chờ và tiếp tục chạy. Thread cha Join Wait l Thread | Thread con cha phải chờ (bị | blocked) trong khi | da chay xong Thread con dang | chay | Thread con Join Release Thread cha Thread cha tiép tuc chay 3.

Exit Khi một Thread đã hoàn thành công việc của mình và muốn kết thúc, nó cần phải chờ tất cả các Thread con của nó hoàn thành hết, thì nó mới được Exit. Việc chờ các thread con này được phối hợp dựa trên một Semaphore, và sử dụng ExitWaitQ đề gọi. Mỗi khi 1 Thread hoàn thành xong công việc, và tất cả các thread con của nó cũng đã hoàn thành xong, thì Thread này sẽ cho phép Thread cha của nó (nếu có) tiếp tục thực hiện công việrc của mình bằng cách ExitRelease() Gia sur, ta khong str dung Exit ma chi str đụng mỗi Join, thì Nachos sẽ ngay lập tức kết thúc chương trình ngay khi Thread con đầu tiên hoàn thành công việc. Exit Wait Thread con chờ (bị blocked) trong khi các Thread chau chay Thread cháu chạy xong xong Exit Release Thread con Exit Release Thread cha Các lớp cân tìm hiêu 1.

PTable Lớp PTable được sinh ra để quản lý toàn bộ tiến trình trong trong Nachos. Trong cài đặt của nhóm, chỉ có 1 thể hiện duy nhất của lớp PTable được sử dụng toàn cục trong toàn bộ Nachos, đây chính là P7able* pTab được khai báo và khởi tạo toàn cục ở file sụsfem.cc, Lớp PTable được khai báo và cài đặt lần lượt ở P7abie.cc Dưới đây là thông tim của lớp PTable Tén Loai Kiêu dữ liệu Nội dung Ghi chú MAXPROCES | Hăng sô Sô lượng Được cung câp 3 process tôi đa | bởi giáo viên mà nhóm cho phép Nachos được chạy khi chạy đa chương bm Thuộc tính BitMap* Quan lý các đôi | Được cung câp tượng PCB bởi giáo viên đã/đang/sẽ/chư a được dùng pcb Thuộc tính PCB* Mảng lưu trữ Được cung câp các PCB được bởi giáo viên quản lý gián tiếp bởi bm Số lượng phần tử tôi đa của mang: MAXPROCES 5 psize Thuộc tính int Kích thước Được cung câp khởi tạo của bởi giáo viên BitMap = Số lượng phân tử sử dụng của pcb <= MAXPROCES Ss bmsem Thuộc tính Semaphore* Semaphore Được cung câp dùng đê xử lí bởi giáo viên độc quyền truy xuất trên các phương thức của PTable PTable(int size) Constructor Ptable Phương thức Được cung câp khởi tạo cho bởi giáo viên PTable, với tham số size chinh la psize can nap vao dé khởi tạo ~PTable() Destructor Phương thức Được cung câp huỷ cho PTable bởi giáo viên ExecUpdate(ch Phương thức int Input: tén cua Được cung câp ar* filename) file chuong bởi giáo viên trình cần chạy Output: process 1d của chương trình đây khi chạy đa chương Chức năng: Khởi chạy l tiễn trình có tên là filename trong nachos ExitUpdate(in Phương thức int Input: exit code Được cung câp ec) cua tién trinh bởi giáo viên dang chay Output: exit code cuối cùng của tiên trình đây Chức năng: Cho phép kết thúc quá trỉnh Join của | tién trinh khi no da chay xong JoinUpdate(mt Phương thức int Input: process Được cung câp pID) ID của một tiễn bởi giáo viên trình cần thực hién Join Output: exit code khi chay tién trinh day 10 Chức năng: Cho phép thực hiện quá trỉnh Join một tiền trình GetFreeSlot() Phương thức int Input: không có Được cung câp Output: trả về bởi giáo viên một vị trí còn trồng của bm Chức năng: tìm 1 vi tri con trong trén bm để thực hiện chạy đa chương cho l tiến trình mới IsExist(int pID) Phương thức bool Input: process Được cung câp id cha mét tién bởi giáo viên trinh Output: Yes néu tién trình đó có tổn tại (tức là đang chạy, chưa exit), No néu ngược lai Chức năng: Kiểm tra xem liệu l tiễn trình có đang chạy 11 và đã nạp vào trong PTable hay chưa Remove(mt Phương thức void Input: process Được cung câp pID) id cha mét tién bởi giáo viên trinh can loai bỏ ra khỏi PTable Output: không có Chức năng: loại bỏ một tiền trình đã được nạp vảo trong PTable GetName(mt Phương thức char* Input: process Được cung câp pID) 1d của tiền trình bởi giáo viên can lây tên trong PTable Output: tên tương ứng của process id day Chức năng: lấy tên của một chương trình có process 1d tương ứng trong PTable 12 2. PCB Tương ứng với mỗi tiến trình mà ta muốn chạy đa chương khi được nạp vào PTable, sẽ có 1 PCB (Process control block) tương ứng để quản ly l tiến trình đấy. PCB trong đồ án lan này được thể hiện trong chính PCB* bm/A4AXPROCESS] của chinh pTab ma ta da dé cap & phan “1.

PTable” Lớp PCB được khai báo và cài dat lần lượt ở ?CB.