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.
