Chương 7: Bộ nhớ vật lý

7.1 Mở đầu

Việc tổ chức và điều khiển bộ nhớ vật lý là một trong những yếu tố quan trọng nhất xác định cách xây dựng HĐH. Để thực hiện các chương trình hay truy nhập dữ liệu, chúng cần được nạp vào bộ nhớ vật lý. Bộ nhớ ngoài (bộ nhớ thứ cấp như ổ đĩa cứng) thường có dung lượng rất lớn và giá rẻ dùng để chứa chương trình và dữ liệu.

7.2 Tổ chức bộ nhớ

Trước kia bộ nhớ vật lý là tài nguyên đắt nhất. Do đó nó cần được tổ chức tốt để có thể sử dụng với hiệu quả cao nhất. Tổ chức bộ nhớ là cách mà chúng ta hình dung và sử dụng bộ nhớ vật lý. Ví dụ như chúng ta sẽ nạp vào bộ nhớ một chương trình hay nhiều chương trình cùng một lúc? Nếu như trong bộ nhớ có một số chương trình thì mỗi chương trình sẽ được cấp vùng nhớ bằng nhau hay chia bộ nhớ thành các phần (section, part) với kích thước khác nhau. Chúng ta có cần đòi hỏi các chương trình ứng dụng được thiết kế để nạp vào phần bộ nhớ cố định hay cho phép nạp vào bất cứ vùng nào phù hợp. Chúng ta có cần mỗi chương trình nằm trong một vùng nhớ liên tục hay có thể chia chương trình thành các khối nằm trong các vùng nhớ bất kỳ.

7.3 Điều khiển bộ nhớ.

Không phụ thuộc vào cách tổ chức bộ nhớ, chúng ta cần giải quyết cần dùng các tiêu chuẩn nào để đạt được các thông số tối ưu. Các phương pháp điều khiển bộ nhớ xác định cách làm việc của bộ nhớ với tổ chức cụ thể nào đó trong các cách giải quyết khác nhau các vấn đề: chúng ta nạp chương trình vào chỗ nào, nêu như không còn đủ bộ nhớ trống thì chương trình nào đang nằm trong bộ nhớ sẽ phải đưa ra...

7.4 Phân lớp bộ nhớ

Vào những năm 50/60 bộ nhớ vật lý rất đắt. Do đó việc chọn lựa kích thước bộ nhớ vật lý cần phải tính toán trước. Khách hàng không muốn mua lớn hơn anh ta có thể, mặt khác anh ta phải mua một số ít nhất nào đó để đảm bảo hoạt động của HĐH và số lượng định trước các user. Vấn đề là xác định dung lượng bộ nhớ tối thiểu thoả mãn bài toán và đồng thời nằm trong khả năng tài chính cho phép.

Để có thể chạy chương trình hay truy nhập dữ liệu, chúng cần phải được nạp vào bộ nhớ vật lý. Các chương trình và dữ liệu chưa cần có thể lưu trong bộ nhớ ngoài, khi cần thiết sẽ được nạp vào bộ nhớ vật lý. Bộ nhớ ngoài (đĩa cứng,...) thường rẻ hơn và có dụng lượng lớn hơn nhưng thời gian truy cập bộ nhớ vật lý lại nhanh hơn nhiều. Ví dụ về tốc độ truy cập, bộ nhớ vật lý: 60ns, HDD: 9ms.

Hệ thống với các lớp bộ nhớ có đặc tình tần suất trao đổi chương trình, dữ liệu giữa các lớp khác nhau tương đối lớn. Sự trao đổi đó cũng làm hao hụt tài nguyên hệ thống ví dụ thời gian BXL,...

Vào những năm 60 xuất hiện thêm một lớp (ngoài bộ nhớ vật lý và bộ nhớ ngoài) nữa, đó là cache memory, cho phép làm tăng tốc độ và hiệu quả sử dụng bộ nhớ. Cache memory có tốc độ truy cập nhanh hơn nhiều (15ns) so với bộ nhớ vật lý. Nhưng nó cũng đắt hơn nhiều, do đó trong hệ thống thông thường dung lượng cache không lớn.

Cache memory làm tăng thêm một lớp trao đổi nhưng chi phí đó được bù lại bởi tốc độ truy cập. Và do đó tốc độ của cả hệ thống được nâng lên nhiều.

Hình vẽ

7.5 Các chiến lược điều khiển bộ nhớ

Để đảm bảo sử dụng tốt các tài nguyên giá trị, chúng cần được điều khiển một cách có hiệu quả. Các chiến lược điều khiển bộ nhớ theo hướng đảm bảo sử dụng tốt nhất bộ nhớ vật lý, và chia theo các hướng sau:

1/ Chiến lược lựa chọn

a- chiến lược lựa chọn theo yêu cầu (demand fetch)

b- chiến lược lựa chọn trước

2/ Chiến lược phân bố

3/ Chiến lược loại ra

Mục đích của chiến lược lựa chọn là xác định xem khi nào phải nạp block chương trình hay dữ liệu vào bộ nhớ vật lý. Trong nhiều năm người ta cho rằng cách tốt nhất là lựa chọn theo yêu cầu: theo đó block chương trình hay dữ liệu được nạp vào bộ nhớ khi chương trình đang hoạt động đòi hỏi đến. Bởi vì rằng nói chung khó mà nói trước được điều khiển sẽ được chuyển đến đâu (địa chỉ lệnh tiếp theo) và chi phí thêm gắn với việc dự đoán trước sẽ tăng đáng kể thời gian chờ. Còn ngày nay, nhiều nhà thiết kế tin rằng lựa chọn dự đoán trước hoàn toàn có thể đảm bảo tăng tốc độ của hệ thống.

Các chiến lược phân bố có mục đích xác định xem chương trình mới sẽ được nạp vào vị trí nào của bộ nhớ. Chúng ta sẽ xem xét một số chiến lược như 'first suitalbe' (chọn block đầu tiên phù hợp), 'most suitable' (chọn block phù hợp nhất) và 'least suitable' (block ít phù hợp nhất), theo kích thước các vùng trống.

Các chiến lược loại bỏ xác định xem block chương trình hoặc dữ liệu nào sẽ bị loại ra khỏi bộ nhớ để giải phóng chỗ cho việc nạp chương trình hay dữ liệu.

7.6 Phân bố bộ nhớ liên tục và không liên tục

Trong các máy tính đầu tiên bộ nhớ được phân bố liên tục- tức là mỗi chương trình phải nằm trong một vùng nhớ. Chỉ sau khi xuất hiện khái niệm đa chương trình với phân đoạn thay đổi (variable partition multi programming) thì việc phân bố bộ nhớ không liên tục mới chứng tỏ sự hiệu quả của mình.

Trong phân bố bộ nhớ không liên tục, chương trình được chia làm nhiều phân đoạn (block hay segment), và chúng có thể nằm tại các vùng nhớ khác nhau, không nhất thiết phải liền nhau. Về phía HĐH, việc đảm bảo phân bố bộ nhớ không liên tục là rất phức tạp, nhưng nó đem lại nhiều ưu thế: nếu bộ nhớ có nhiều vùng nhớ trống thay vì một vùng lớn thì HĐH vẫn có thể nạp và thực hiện chương trình mà trong trường hợp ngược lại sẽ phải chờ.

7.7 Phân bố bộ nhớ liên tục đối với một user

Trong các máy đầu tiên tại mỗi thời điểm chỉ có một user (một chương trình ứng dụng) và tất cả tài nguyên đều thuộc quyền của anh ta. Và tiền sử dụng máy được tính theo nguyên tắc đơn giản- bởi vì user toàn quyền sử dụng các tài nguyên do đó anh ta phải trả cho tất cả, không phụ thuộc việc chương trình của anh ta có sử dụng hết các tài nguyên hay không. Do đó cơ chế tính tiền thực hiện theo thời gian máy đã sử dụng. Trong các hệ làm việc trong chế độ phân chia thời gian thì việc tính toán sử dụng các thuật toán phức tạp hơn nhiều.

Đầu tiên mỗi user đều phải tự mình viết toàn bộ chương trình kể cả các hàm thực hiện vào/ra bằng ngôn ngữ máy. Sau đó thì phần lệnh thực hiện các thao tác vào/ra cơ bản được đưa vào IOCS- hệ thống điều khiển vào/ra, và người dùng không phải viết lại các hàm vào/ra mà chỉ phải gọi các hàm tương ứng của hệ thống. Điều đó làm đơn giản và tăng hiệu quả lập trình và có thể cho rằng đó là bắt đầu sự phát triển khái niệm về OS hiện đại. Tổ chức bộ nhớ trong trường hợp phân bố liên tục đối với một người dùng được biểu diễn bằng h.7.2

Hình 7.2

Thông thường thì kích thước chương trình phụ thuộc dung lượng bộ nhớ (hay không gian quản lý bởi HĐH), nếu kích thước chương trình nhỏ hơn kích thước bộ nhớ thì không có vấn đề nảy sinh, còn khi kích thước chương trình vượt quá thì sao? Nhờ cơ chế overlay cho phép chúng ta có thể viết các chương trình lớn hơn giới hạn trên. Khái niệm của nó được thể hiện trong hình 7.3. Nếu như module nào đó của chương trình không hoạt động trong cả quá trình thực hiện chương trình thì nó hoàn toàn có thể được lưu trong bộ nhớ ngoài, khi cần thiết mới được nạp vào bộ nhớ vật lý và sau khi kết thúc nó lại được ghi ra bộ nhớ ngoài, giải phóng bộ nhớ vật lý cho module tiếp theo.

Chế độ overlay cho phép lập trình viên thiết kế các chương trình lớn vượt qua hạn chế bộ nhớ. Nhưng việc thiết kế overlay module đòi hỏi nhiều công sức và trí tuệ.

Các chương trình với cấu trúc overlay phức tạp rất khó thay đổi. Ngày nay chúng ta không còn phải dùng chế độ overlay để vượt qua giới hạn về bộ nhớ do đã có các hệ thống với bộ nhớ ảo - virtual memory

Hình 7.3 Cấu trúc overlay

Bảo vệ bộ nhớ trong hệ thống đơn nhiệm

Trong hệ thống đơn nhiệm, user được cấp vùng nhớ liên tục và nói chung là có quyền điều khiển, truy nhập toàn bộ bộ nhớ vật lý. Trong trường hợp này bộ nhớ thường chia làm 3 vùng: vùng cho HĐH, vùng cho chương trình ứng dụng và vùng trống. Vấn đề bảo vệ bộ nhớ trong trường hợp này cũng tương đối đơn giản. Bảo vệ bộ nhớ trong trường hợp này là bảo vệ HĐH để chương trình ứng dụng không làm hỏng nó.

Nếu như chương trình hoạt động không đúng, điều đó có thể dẫn tới phá vỡ HĐH, nếu như HĐH bị hỏng đến mức chương trình khác ứng dụng không thể tiếp tục hoạt động thì người dùng ít nhất cũng nhận thấy, sửa lỗi và chạy lại chương trình. Trong trường hợp này thì sự cần thiết bảo vệ HĐH không phải là rõ ràng.

Nếu trong trường hợp khác, chương trình ứng dụng phá hỏng HĐH một cách 'tinh vi'. Ví dụ như nó 'vô tình' làm thay đổi một hàm vào/ra của hệ thống. Khi đó chương trình có thể vẫn hoạt động nhưng tất cả kết quả có thể bị mất. Còn có thể xảy ra trường hợp tồi tệ hơn là hệ thống đưa ra kết quả sai mà việc phát hiện ra không dễ dàng.

Do đó rõ ràng cần phải bảo vệ HĐH. Việc bảo vệ có thể thực hiện bằng thanh ghi biên nằm trong BXL (h.7.4)

Hình 7.4

Thanh ghi biên chứa địa chỉ thấp nhất của lệnh. Nếu như user cố gắng truy nhập vào vùng của HĐH thì lệnh đó bị cấm và sẽ đưa ra thông báo lỗi.

Tất nhiên, user cũng cần truy nhập đến HĐH, ví dụ như thực hiện các thao tác vào/ ra. Để phục vụ điều này user có thể dùng các lệnh đặc biệt, với chúng anh ta có thẻ yêu cầu dịch vụ nào đó của HĐH (ví dụ như ngắt SVC) Trong trường hợp này OS thực hiện dịch vụ được yêu cầu và sau đó trả lại điều khiển cho chương trình ứng dụng.

Với việc OS ngày càng phức tạp, cần phải có các cơ chế tốt hơn để bảo vệ OS đối với user cũng như giữa các user với nhau.

7.8 Đa chương trình với các đoạn cố định (fixed partition multiprogramming)

Đối với các hệ thống đơn nhiệm và ngay cả hệ thống xử lý gói (packeg processing) thì vẫn bị lãng phí một phần đáng kể tài nguyên. Trên h.7.5 ta thấy rằng chương trình chỉ thực sự sử dụng BXL khi mà nó không thực hiện thao tác vào/ra. Sau khi bắt đầu thao tác vào/ra chương trình không thể tiếp tục cho đến khi kết thúc thao tác. Tốc độ thực hiện thao tác vào/ra thường chậm hơn nhiều so với tốc độ của BXL. Như vậy BXL bị bỏ phí trong suốt thời gian chờ thực hiện tác vụ vào/ra, và phần này chiếm đáng kể thời gian chung.

Hình 7.5 Sử dụng BXL trong hệ thống đơn nhiệm

Các nhà thiết kế thấy rằng hoàn toàn có thể tăng hiệu quả sử dụng BXL. Họ đã thực hiện các hệ thống đa nhiệm, trong đó các user cùng 'cạnh tranh' để có được tài nguyên. Chương trình đang chờ kết thúc thao tác vào/ra sẽ phải nhường BXL cho chương trình đã sẵn sàng hoạt động (tất nhiên nếu có chương trình như thế). Do đó đảm bảo khả năng cùng thực hiện thao tác vào/ra và BXL- nâng cao hiệu quả sử dụng BXL và cả hệ thống.

Các ưu thế của multiprogramming chỉ có thể tận dụng hết khi trong bộ nhớ có nhiều chương trình. Nhờ đó khi một chương trình thưc hiện thao tác vào/ra thì BXL có thể chuyển sang phục vụ chương trình khác và thực hiện tính toán với thời gian trễ nhỏ nhất. Khi chương trình thứ hai giải phóng BXL thí đến chương trình thứ ba khác lại có thể sẵn sàng sử dụng nó.

Multiprogramming đòi hỏi dung lượng bộ nhớ lớn hơn so với trường hợp đơn nhiệm nhưng chi phí đó được bù lại bởi việc sử dụng hiệu quả các tài nguyên khác (BXL, thiết bị vào/ra)

7.8.1 Fixed partition multiprogramming (đa nhiệm với phân đoạn cố định) dịch và nạp theo chương trình theo địa chỉ tuyệt đối

Trong các hệ đa nhiệm đầu tiên, bộ nhớ được chia thành các phần (phân đoạn) với kích thước cố định. Trong mỗi đoạn chỉ có thể nạp một chương trình. Còn BXL nhanh chóng chuyển từ chương trình này sang chương trình khác, do đó tạo ra hiệu quả là tất cả chương trình dường như được thực hiện đồng thời.

Việc biên dịch chương trình được thực hiện bởi assembler và compiler với địa chỉ tuyệt đối bị giới hạn bởi việc chương trình chỉ có thể chạy trong một phân đoạn cụ thể (h.7.6)

Hình 7.6

Nếu như chương trình đã sẵn sàng nhưng phân đoạn của nó đã có chương trình khác thì nó phải đợi dù rằng các phân đoạn khác có thể trống (h.7.7). Điều này dẫn tới sự lãng phí bộ nhớ nhưng việc thiết kế OS lại tương đối đơn giản.

Trên hình 7.7 thể hiện tình huống xấu nhất của phương pháp phân bố bộ nhớ liên tục với phân đoạn cố định và chương trình được dịch và nạp vào địa chỉ tuyệt đối (phân đoạn cố định). Cả hai phân đoạn một và hai đều bỏ phí còn hàng chờ của phân đoạn ba quá nhiều trong khi chúng đã có thể được nạp vào phân đoạn một và hai.

Hình 7.7

7.8.2 Đa nhiệm với phân đoạn cố định: dịch và nạp chương trình các module tự do.

Các chương trình dịch, assembler và loader tự do được sử dụng để dịch và nạp các chương trình có thể thực hiện tại bất cứ phân đoạn trống nào đủ lớn (hình 7.8). Phương pháp này khắc phục được một số nhược điểm về sử dụng bộ nhớ trong trường hợp trước (đa nhiệm với phân đoạn cố định, dịch và nạp chương trình theo địa chỉ tuyệt đối). Nhưng để đạt được điều đó, việc thiết kế lại phức tạp hơn nhiều.

Hình 7.8

7.8.3 Bảo vệ bộ nhớ trong các hệ đa nhiệm

Trong các hệ thống đa nhiệm với phân bố bộ nhớ liên tục (contiguous memory allocation), thường người ta sử dụng các thanh ghi biên để bảo vệ bộ nhớ. Hai thanh ghi chỉ ra cận dưới và cận trên của phân đoạn, hoặc một cận và kích thước của phân đoạn; chương trình có yêu cầu truy nhập đến các dịch vụ của OS phải dùng ngắt SVC để yêu cầu.

Hình 7.9

7.8.4 Vấn đề chia nhỏ bộ nhớ (fragmentation) trong đa chương trình với phân đoạn cố định

Fragmentation xảy ra trong bất kỳ hệ thống nào không phụ thuộc vào tổ chức bộ nhớ. Trong các hệ đa nhiệm với các phân đoạn cố định, fragmentation xảy ra do các chương trình ứng dụng không chiếm hết toàn bộ phân đoạn của nó hoặc là do các phân đoạn quá nhỏ để có thể nạp các chương trình đang chờ vào đó.

7.9 Đa nhiệm với các phân đoạn thay đổi

Khi xem xét các vấn đề của đa nhiệm với phân đoạn cố định, các kỹ sư thiết kế OS thấy rằng tốt hơn là cho phép các chương trình chỉ chiếm bộ nhớ kích thước vừa đủ kích thước nó cần. Không chia bộ nhớ thành các đoạn cố định mà có kích thước thay đổi theo chương trình ứng dụng. Phương pháp đó gọi là đa nhiệm với các phân đoạn thay đổi. Sự phân bố bộ nhớ ban đầu được thể hiện trong h.7.10

Chúng ta chỉ xem xét phương pháp phân chia bộ nhớ liên tục tức là mỗi chương trình nạp vào vùng nhớ liên tục. Trong phương pháp đa nhiệm với các phân đoạn thay đổi chúng ta không đề ra bất cứ giả sử gì về chương trình (trừ khi kích thước của chúng không vượt quá kích thước bộ nhớ). Các chương trình khi được nạp (thực hiện) sẽ được cấp vùng nhớ chúng cần. Mỗi phân đoạn có kích thước đúng bằng kích thước chương trình nằm trong đó.

Hình 7.10

Mỗi sơ đồ tổ chức bộ nhớ đều có sự lãng phí nhất định. Trong trường hợp đa nhiệm với các phân đoạn thay đổi, sự lãng phí này xuất hiện khi các chương trình kết thúc và trong bộ nhớ xuất hiện các vùng trống (hole) như h.7.11. Các vùng trống này có thể sử dụng để nạp các chương trình khác nhưng dù sao vẫn sẽ còn các vùng trống vì không phải các chương trình đều có kích thước đúng bằng vùng trống. Như vậy đa nhiệm với các phân đoạn thay đổi vẫn không tránh khỏi lãng phí bộ nhớ.

Hình 7.11

7.9.1 Hợp nhất các vùng trống liền nhau

Để khắc phục tình trạng bộ nhớ bị chia nhỏ chúng ta có thể dồn các vùng nhớ trống kể nhau.

Trong đa nhiệm với các phân đoạn thay đổi, khi một chương trình kết thúc chúng ta có thể kiểm tra xem vùng được giải phóng có nằm liền kề với vùng trống khác không? Nếu tồn tại thì chúng ta có thể hoặc đưa thêm vào danh sách các phân đoạn trống thêm một bản ghi nữa hoặc nối liền với vùng trống liền kề thành một vùng trống. Quá trình hợp nhất (nối liền) các vùng trống kề nhau biểu diễn trên hình 7.12. Nhờ sự hợp nhất này mà chúng ta tạo được các vùng nhớ liên tục với kích thước lớn nhất có thể.

Hình 7.12

7.9.2 Dồn bộ nhớ

Như chúng ta thấy sau khi thực hiện hợp nhất các vùng trống (holes) liền kề nhau thì nhìn tổng thể thì trong bộ nhớ vẫn tồn tại các vùng trống - cho dù ít hơn và kích thước lớn hơn. Đôi khi chương trình cần thực hiện tiếp theo lại khó lớn đến mức không có vùng trống nào đủ lớn để nạp cho dù tổng cộng kích thước các vùng trống vẫn lớn hơn cần thiết.

Vấn đề này được khắc phục nhờ phương pháp gọi là dồn bộ nhớ (h.7.13) và bản chất là chuyển (dồn) tất cả các phân đoạn đang có chương trình về một phía bộ nhớ. Nhờ đó thay vì có nhiều phân đoạn trống (vùng trống) vụn vặt chúng ta có được một vùng trống lớn duy nhất trong bộ nhớ. Khi đó chương trình tiếp theo có xác suất lớn sẽ có đủ bộ nhớ cần thiết để chạy. Đôi khi phương pháp 'dồn bộ nhớ' còn gọi là 'dọn rác'.

Tuy có nhiều ích lợi nhưng phương pháp dồn bộ nhớ vẫn có những nhược điểm nhất định:

Nó cũng làm hao phí tài nguyên hệ thống có thể được sử dụng vào mục đích khác tốt hơn.

Vào thời gian dồn bộ nhớ, hệ thống phải dừng tất cả các công việc khác. Kết quả dần tới thời gian không thể dự đoán trước trong việc phản ứng lại các sự kiện (trả lời user trong chế độ dialog chẳng hạn) và điều đó có thể không chấp nhận được trong các hệ thống thời gian thực.

Dồn bộ nhớ dịch chuyển các task trong bộ nhớ. Điều đó có nghĩa là thông tin về sự phân bố chương trình phải được lưu lại ở dạng nào đó.

Trong TH các bài toán thực hiện liên tục thì tần số thực hiện thao tác dồn bộ nhớ có thể trở nên thường xuyên và hao phí thực hiện nó có thể vượt quá lợi ích nó mang lại.

Hình 7.13

7.9.3 Các chiến lược phân bố thông tin trong bộ nhớ.

Các chiến lược phân bố bộ nhớ được áp dụng để xác định chương trình và dữ liệu sẽ được tiếp tục nạp vào vùng nào của bộ nhớ. Chúng ta thường gặp 3 chiến lược được biểu diễn trên h.14

1. Chiến lược 'first suitable': chương trình sẽ được nạp vào vùng trống gặp đầu tiên (trong danh sách các vùng trống) có kích thước đủ lớn. Chiến lược này có vẻ trực giác và thực tế vì nó cho phép tìm lời giải nhanh nhất.

2. Chiến lược 'most suitable': Chương trình được nạp vào vùng trống 'vừa nhất' do đó không gian lãng phí là ít nhất. Với nhiều người thì chiến lược này trực giác có vẻ là đúng nhất.

3. Chiến lược 'least suitable': đầu tiên thì chiến lược này có vẻ lạ lùng, nhưng xem xét kỹ thì nó cũng có các ưu điểm nhất định. Với chiến lược này chương trình nạp vào vùng trống lớn nhất. Ưu điểm là sau khi đã nạp chương trình, vẫn còn đủ không gian trống tương đối lớn đẻ có thể nạp thêm chương trình mới khá lớn.

Hình 7.14

7.10 Đa nhiệm với swapping

Trong các hệ đa nhiệm đã xem xét ở trên thì chúng ta đều giả sử rằng chương trình ứng dụng luôn nằm trong bộ nhớ đến khi nó kết thúc. Còn có cơ chế khác gọi là swapping mà không cần điều kiện đó.

Trong một số hệ thống dùng swapping (h.7.15) thì mỗi thời điểm trên cả bộ nhớ chỉ có một chương trình ứng dụng. Chương trình đó thực hiện đến khi có thể sau đó nó giải phóng cả BXL và bộ nhớ để cho chương trình tiếp theo. Như thế, toàn bộ bộ nhớ được giành cho một chương trình trong khoảng thời gian ngắn, và sẽ bị đưa ra khỏi bộ nhớ, chương trình tiếp theo được nạp vào bộ nhớ. Bình thường thì một chương trình trong quá trình chạy từ đầu đến lúc kết thúc sẽ bị swap nhiều lần.

Trong các hệ thống phân chia thời gian có sử dụng swapping, khi số chương trình khá ít thì hệ thống có thể đảm bảo thời gian trả lời chấp nhận được, còn khi số chương trình nhiều thì các nhà thiết kế hiểu rằng cần có các phương pháp và công cụ hiệu quả hơn. Trên cơ sở hệ thống với swapping đầu những năm 60, người ta đã xây dựng nhiều hệ thống với sự tổ chức bộ nhớ theo trang (page) và ngày nay trở nên thông dụng.

Cũng đã có xây dựng các hệ thống phức tạp hơn với swapping, trong đó cho phép phân bố trong bộ nhớ nhiều chương trình. Trong các hệ thống đó, chương trình bị đưa ra khỏi bộ nhớ chỉ khi vùng bộ nhớ của nó cần thiết để nạp chương trình khác. Trong TH dung lượng bộ nhớ khá lớn thì các hệ thống đó hoạt động tốt hơn đáng kể do giảm được thời gian thực hiện swapping.

Hình 7.15

Hệ thống đa nhiệm với swapping, tại mỗi thời điểm chỉ có một chương trình trong bộ nhớ. Chương trình đó tiếp tục đến khi có một trong các sự kiện sau xảy ra:

Xuất hiện tín hiệu timer

Nó kết thúc

Vùng swapping của chương trình đó sẽ được copy vào bộ nhớ ngoài, còn ảnh bộ nhớ của chương trình tiếp theo sẽ được nạp vào vùng swapping. Chương trình thứ hai tiếp tục được thực hiện, quá trình cứ thế tiếp tục.