P N( ∆t) = 1 j= 1 λ∆t (2.13)
2.3.1 Các điều kiện chạy đua và các giai đoạn tới hạn
Người ta nhận thấy rằng, ở một trong nhiều hàng đợi của hệ thống tiến trình, thì nhiều tiến trình được treo vào và chờ đợi sự điều khiển. Tình trạng này luôn luôn trở lại xuất hiện trong các hàng đợi và cũng được chỉ ra trên hình 2.19.
Hình 2.19.Các điều kiện chạy đua ở một hàng đợi
Về điều đó, chưa có thể phân biệt các trạng thái rằng, hoặc là một tiến trình mới được treo vào (ở đây là tiến trình A) hoặc là một tiến trình đang tồn tại được treo vào (ở đây là tiến trình B).
Để treo vào hay bứt ra, tiến hành những bước sau đây:
Treo vào: Bứt ra:
(1) Lấy móc treo: PointToB (1) Lấy móc treo: PointToB (2) Lập dấu chỉ dẫn kế cạnh : = PointToB (2) Lập dấu chỉ dẫn kế cạnh
:= PointToB
(3) Đặt móc treo:= PointToA (3)Đặt móc treo:= PointToC Sau khi bứt ra một tiến trình thì không gian nhớ của việc ghi chép danh sách được trả lại tự do và một sự chuyển đổi tiến trình được đón nhận với dấu hiệu chỉ dẫn tới khối điều khiển tiến trình.
Mỗi một trong các tác vụ tiến hành tốt, cho đến khi, nó được thực hiện cho chính nó (trong một khoảng thời gian ngắn). Nếu chúng ta có một hệ thống các tiến trình, rằng một sự chuyển đổi bất kỳ sau một lệnh trong khoảng một tác vụ của một tiến trình, thì với cái đó, tạo điều kiện cho một sự chuyển đổi kịp thời của một tác vụ khác. Bây giờ, chúng ta khảo sát bước đầu tiên của tác vụ “bứt ra” tiến trình. Chúng ta nhận thấy: tiến trình B cần thiết phải được bứt ra, tức là bước (1) và (2) được thực hiện để bứt tiến trình rạ Bấy giờ xuất hiện một ngắt thời gian, lát
Móc treo PointTo B A B C PCB(A) PCB(B) PCB(C)
cắt thời gian của B là cuối cùng. Tiến trình A xuất hiện và treo vào danh sách trong khoảng tác vụ “treo vào”; nó còn tạo thêm một việc gì đó hay nằm yên. Nếu bây giờ B lại nhận sự điều khiển, do đó B tiếp tục làm việc một cách khó nhọc với các dữ liệu cũ. Trong bước thứ (3), móc treo được đặt vào vị trí C và với cái đó, thì tiến trình A không còn ở trong danh sách nữa; nếu đó là danh sách sẵn sàng, thì khi đó không nhận sự điều khiển nữa và cũng không làm việc.
Sự xảo trá của lỗi này là ở chỗ: nó không xuất hiện luôn luôn, mà chỉ xuất hiện một cách phiếm định, một cái gì đó không rõ ràng, một cách không thể tái định và nó chỉ xuất hiện do những điều kiện phụ được kết nốị Vì có cái đó xẩy ra, cho nên nếu, một tiến trình chạy vượt qua một tiến trình khác, thì người ta chỉ cái đó là điều kiện chạy đua; đó là một đoạn mã mà trong đó lỗi tồn tại; và tất nhiên, các đoạn mã này không được phép bẻ gãy, chúng là những đoạn mã tới hạn (critical section).
Vấn đề này là đặc trưng cho mọi hệ thống, mà ở đó, nhiều phương tiện điều hành độc lập làm việc trên một dải dữ liệụ Đặc biệt tại những hệ thống đa vi xử lý, thì cái đó là một vấn đề quan trọng được các nhà thiết kế hệ thống nhận biết và quan tâm.
Vấn đề cơ bản là ở chỗ phải đảm bảo an toàn đối với mỗi khoảng tới hạn ở trong chương trình người sử dụng hay ở trong hệ điều hành: tức là tại đó luôn luôn chỉ có một tiến trình hay một vi xử lý. Việc dẫm lên hay loại bỏ mã phải được xác định đồng bộ giữa các tiến trình và phải đảm bảo một sự loại bỏ tương tác (mutial exclusion) ở trong khoảng tới hạn.
Vấn đề này đã được nhận biết trong những năm 60 và đã được xử lý với nhiều thuật toán khác nhaụ Ở phương pháp giải quyết của ẸW. Dijkstra (1965) đã đưa ra những yêu cầu sau đây:
+ Hai tiến trình không được đồng thời ở trong khoảng tới hạn của chúng; + Không được phép hãm một tiến trình ngoài khoảng tới hạn của một tiến trình khác;
+ Mỗi tiến trình đang chờ ở lối vào của một khoảng tới hạn, thì nó phải được phép dẫm lên khoảng tới hạn: Một sự chờ đợi vỉnh viễn phải được chấm dứt (fairness condition).