Tại sao trạng thái không an toàn không phải lúc nào cũng gây ra bế tắc?

Tôi đang đọc Hệ điều hành của Galvin và tình cờ thấy dòng dưới đây,

Tuy nhiên, không phải tất cả các trạng thái không an toàn là bế tắc. Một trạng thái không an toàn có thể dẫn đến bế tắc

Ai đó có thể vui lòng giải thích làm thế nào bế tắc! = Trạng thái không an toàn ? Tôi cũng bắt được dòng tương tự ở đây

Nếu một chuỗi an toàn không tồn tại, thì hệ thống ở trạng thái không an toàn, điều này có thể dẫn đến bế tắc. (Tất cả các trạng thái an toàn là bế tắc miễn phí, nhưng không phải tất cả các trạng thái không an toàn đều dẫn đến bế tắc.)

Bế tắc có nghĩa là một cái gì đó cụ thể: có hai (hoặc nhiều) quá trình hiện đang bị chặn chờ nhau.

Trong trạng thái không an toàn, bạn cũng có thể rơi vào tình huống có thể xảy ra bế tắc trong tương lai, nhưng điều đó chưa xảy ra vì một hoặc cả hai quá trình chưa thực sự bắt đầu chờ đợi.

Hãy xem xét ví dụ sau:

Process A                  Process B
lock X                     lock Y           # state is "unsafe"
                           unlock Y
lock Y                                      # state is back to "safe" (no deadlock this time.  We got lucky.)

Có một ví dụ thú vị hơn trong Phần 7.5.1 của liên kết bạn đã đưa ra :

Hãy xem xét một hệ thống có 12 ổ băng với:

Process       Max Need       Current
P0:             10              5
P2:              9              3

Đây là một trạng thái không an toàn. Nhưng chúng ta không rơi vào bế tắc. Chỉ có 4 ổ đĩa miễn phí, vì vậy, ví dụ, nếu P0 không yêu cầu thêm 5, và P2 không yêu cầu thêm 1, chúng ta sẽ bế tắc, nhưng nó chưa xảy ra. Và P0 có thể không yêu cầu thêm ổ đĩa, nhưng thay vào đó có thể giải phóng các ổ đĩa mà nó đã có. Các Max needkết thúc tất cả thực hiện tốt các chương trình, và sức mạnh đây không phải là một trong những hành nơi chúng tôi cần tất cả 10 ổ đĩa trong P0.

Chỉ để giải thích những gì Logic lang thang đang nói.

Nói rằng tôi có hai luồng mà cả hai đều cần truy cập vào X và Y, và không có đồng bộ hóa và không có cơ chế để sửa lỗi bế tắc. Điều này không an toàn, vì người ta có thể khóa X và người Y khác và sau đó không thể tiến hành. Nhưng nó không được đảm bảo.

Thread 1                    Thread 2
Lock X                      
Lock Y
OS Interrupts Thread 1 and passes control to Thread 2
                            Unable to lock needed resources.
OS Interrupts Thread 2 and passes control to Thread 1
Unlock X                    
Unlock Y                    
                            Lock Y
                            Lock X
 ....

Kịch bản này đã không kết thúc trong bế tắc, nhưng nó có thể có. Do cách phân luồng hoạt động, không có luồng được thiết lập. HĐH kiểm soát luồng và do đó nó có thể xảy ra như sau:

Thread 1                    Thread 2
Lock X        
OS Interrupts Thread 1 and passes control to Thread 2
                            Lock Y              
DEADLOCK Thread 1 needs Y, Thread 2 needs X. Neither knows to back down and simply waits.

Trạng thái an toàn là bế tắc miễn phí, nhưng nếu bạn không thể thực hiện tất cả các yêu cầu để ngăn chặn bế tắc thì điều đó có thể xảy ra. Ví dụ: nếu hai luồng có thể rơi vào bế tắc khi chúng bắt đầu luồng A, sau đó là luồng B, nhưng khi chúng bắt đầu ngược lại (B, A) thì chúng sẽ hoạt động tốt - hãy giả sử B là đẹp hơn;) Trạng thái của hệ thống không an toàn, nhưng với chuỗi khởi đầu may mắn, nó sẽ hoạt động. Không bế tắc, nhưng nó có thể. Nếu bạn cũng đồng bộ hóa chúng bằng tay - bắt đầu theo thứ tự tốt - thật nguy hiểm - vì một số lý do chúng có thể không được kích hoạt như bạn muốn - hệ thống vẫn không an toàn (vì có thể bị bế tắc) nhưng khả năng đó là thấp. Trong trường hợp một số sự kiện bên ngoài như đóng băng chủ đề hoặc gián đoạn sau khi tiếp tục, nó sẽ thất bại.

Bạn phải nhận ra - trạng thái an toàn là điều kiện đủ để tránh bế tắc, nhưng không an toàn chỉ là điều kiện cần thiết. Ngay bây giờ thật khó để viết mã ra khỏi đầu, nhưng tôi có thể tìm kiếm một số. Tôi đã gặp mã trong Ada rằng hơn 99/100 lần nó hoạt động hoàn hảo trong vài tuần (và sau đó dừng lại do máy chủ khởi động lại không bế tắc) nhưng thỉnh thoảng nó bị sập sau vài giây ở trạng thái bế tắc.

Hãy để tôi thêm một số ví dụ dễ dàng bằng cách so sánh với phép chia: Nếu hàm của bạn chia c / d và trả về kết quả, mà không kiểm tra xem d có bằng 0 hay không, có thể có chia cho lỗi không, vì vậy mã không an toàn (cùng tên dự định), nhưng cho đến khi bạn thực hiện phân chia như vậy, mọi thứ đều ổn, nhưng sau khi mã phân tích lý thuyết không an toàn và có thể rơi vào hành vi không xác định không được xử lý đúng cách.

Dưới đây là sự hiểu biết của tôi về điều này (vui lòng sửa cho tôi nếu tôi sai): (A) Nếu bế tắc, có nghĩa là tồn tại một chu kỳ (một trong những điều kiện cần thiết) (B) Một chu kỳ là điều kiện bắt buộc cho bế tắc (cho cả đơn và đa tài nguyên cá thể)

Vì vậy, bây giờ chúng ta có thể chứng minh rằng tồn tại một chu kỳ có thể không dẫn đến bế tắc, Bạn có thể thấy ở đây một chu trình tồn tại có nghĩa là một trạng thái không an toàn được tìm thấy, nhưng điều này có thể không dẫn đến bế tắc vì tài nguyên R2 đang tham gia vào chu kỳ có thể phá vỡ quay vòng ngay khi quá trình P3 kết thúc và giải phóng nó (hãy nhớ rằng P3 không có bất kỳ sự phụ thuộc nào hoặc chờ đợi bất kỳ tài nguyên nào khác).

Trạng thái không an toàn tầm thường: Chủ đề 1 lấy khóa A, sau đó khóa B, sau đó mở khóa cả hai. Chủ đề 2 lấy khóa B, sau đó khóa A, sau đó mở khóa cả hai.

Điều này sẽ chỉ dẫn đến bế tắc nếu Chủ đề 2 lấy khóa B ngay giữa Chủ đề 1 lấy khóa A và cố gắng khóa B hoặc Chủ đề 1 mất khóa A ngay giữa Chủ đề 2 lấy khóa B và cố gắng khóa A.

Nếu Chủ đề 1 và Chủ đề 2 thực hiện việc này một cách ngẫu nhiên mỗi giờ một lần và có một khoảng cách thời gian là micro giây sẽ thực sự dẫn đến bế tắc. điều này có thể chạy rất lâu trong tay khách hàng cho đến khi cuối cùng bạn gặp bế tắc một cách tình cờ.

Đi qua một con phố với đôi mắt nhắm nghiền. Nó không an toàn. Nhưng bạn không luôn luôn bị giết.