15.

4 Phát hiện bế tắc trong mô hình truyền thông OR

Như đã thấy trong Phần. 15.1, trong mô hình truyền thông OR, mỗi câu lệnh nhận chỉ
định một tập hợp các quy trình và tiến trình gọi pi sẽ đợi một thông báo từ bất kỳ quy
trình nào trong số này. Tập các tiến trình này là tập phụ thuộc hiện tại của pi, ký hiệu là
dep_seti. Ngay khi một tin nhắn từ tiến trình dep_seti đến, pi sẽ ngừng chờ đợi và sử dụng
nó. Phần này trình bày một thuật toán phát hiện deadlock trong mô hình này. Thuật toán
này là do K.M. Chandy, J. Misra và LM Haas (1983).
Thuật toán này xem xét định nghĩa được sửa đổi đôi chút sau đây cho một tập các tiến
trình bị bế tắc, cụ thể là một tập hợp các tiến trình D bị bế tắc nếu (a) tất cả các tiến trình
của D là thụ động, (b) tập phụ thuộc của mỗi tiến trình trong số chúng là một tập con của
D, và (c) với mỗi cặp tiến trình {pi,pj } ∈ D sao cho j ∈ dep_seti, không có thông điệp nào
truyền từ pj đến pi. Khi so sánh với định nghĩa được đưa ra trong Mục. 15.1.4, định nghĩa
này bao gồm các quy trình bị chặn bởi các quy trình thuộc một nút của các quy trình bị bế
tắc. Khi xem xét đồ thị chờ ở bên trái của Hình 15.1, định nghĩa này coi p4 là sự bế tắc,
trong khi định nghĩa của Phần. 15.1.4 coi nó bị chặn bởi một tiến trình bế tắc (p2).
Thuật toán này cũng giả định rằng một tiến trình pi chỉ bị động khi nó đang chờ một
thông báo từ một tiến trình thuộc tập phụ thuộc hiện tại của nó dep_seti, có nghĩa là các
tiến trình không kết thúc. Trường hợp một quá trình kết thúc cục bộ (tức là đạt được
tuyên bố “kết thúc”, sau đó nó mãi mãi bị động) được giải quyết trong Vấn đề 4.
15.4.1 Nguyên tắc
Truyền tải mạng với phản hồi Khi người quan sát obsi liên kết với một quá trình pi nghi
ngờ rằng pi có liên quan đến sự bế tắc, nó sẽ khởi chạy một quá trình truyền tải mạng
song song với phản hồi trên các cạnh của đồ thị chờ mà nó là nguồn gốc, tức là trên các
kênh từ pi đến pj như vậy đó j ∈ dep_seti. ((Thuật toán truyền tải mạng với phản hồi xây
dựng cây bao trùm đã được trình bày trong Phần 1.2.4.) Nếu quá trình pj như vậy đang
hoạt động, nó sẽ loại bỏ thông báo và do đó, dừng quá trình truyền tải mạng. Nếu bản
thân nó bị chặn, nó sẽ truyền tải mạng tới các tiến trình hiện đang xác định tập dep_setj
của nó. Và như thế. Các thông báo điều khiển này được sử dụng để xây dựng cây bao
trùm bắt nguồn từ số pi.

Hình 15.6 Biểu đồ truyền thông có hướng

Nếu quá trình truyền tải mạng với phản hồi kết thúc (tức là obsi nhận được câu trả lời từ
mỗi quy trình pj trong dep_seti), mục đích là cho phép obsi bao gồm pi bị bế tắc. Nếu một
người quan sát obsj đã dừng cục bộ tiến trình truyền tải mạng do obsi khởi chạy, thì pi sẽ
hoạt động và trong tương lai có thể gửi một tin nhắn đến quá trình pk đã gửi cho nó một
tin nhắn truyền tải mạng. Nếu được kích hoạt lại, quy trình pk này có thể lần lượt kích
hoạt lại một quy trình p sao cho dep_setk, v.v. Chuỗi kích hoạt lại quy trình này có thể kết
thúc bằng việc kích hoạt lại pi.
Khó khăn trong việc quan sát tính toán phân tán Các thuật toán truyền tải mạng được
trình bày trong Chương. 1 hãy xem xét một mạng tĩnh cơ bản. Ngược lại, mạng được xác
định bởi mối quan hệ chờ (biểu đồ chờ) không tĩnh: nó được sửa đổi bằng tính toán. Do
đó, vấn đề sau: Có thể sử dụng thuật toán truyền tải mạng được thiết kế cho biểu đồ tĩnh
để thực hiện quan sát phân tán nhất quán về biểu đồ có thể được sửa đổi linh hoạt trong
quá trình quan sát của nó không?
Truyền tải mạng với phản hồi trên biểu đồ truyền thông tĩnh có hướng Đặt TRUY
VẤN là loại thông báo thực hiện việc truyền tải mạng trên biểu đồ chờ và TRẢ LỜI loại
thông báo thực hiện phản hồi liên quan. (Các thông báo này được gõ lần lượt là ĐI và
QUAY LẠI trong quá trình truyền tải mạng với thuật toán phản hồi được mô tả trong
Hình 1.7).
Chúng ta hãy xem xét một tính toán bốn quá trình sao cho ở cấp độ ứng dụng, đồ thị
truyền thông là đồ thị có hướng được mô tả trong Hình 15.6. Ở cấp độ cơ bản, các kênh
là hai chiều dành cho các thông báo điều khiển được trao đổi bởi người quan sát quá
trình. Chúng ta hãy xem xét trường hợp người quan sát cục bộ obs1 khởi chạy truyền tải
mạng có phản hồi. Việc truyền tải mạng này được mô tả trong Hình 15.7, trong đó chỉ số
dưới (x,y) được đính kèm với một tin nhắn có nghĩa là tin nhắn này được gửi bởi obsx tới
obsy. Đầu tiên obs1 gửi tin nhắn TRUY VẤN() tới cả ob2 và obs3 (tin nhắn TRUY
VẤN1,2() và TRUY VẤN1,3()), sau đó ob2 chuyển tiếp truyền tải mạng

Hình 15.7 Truyền tải mạng với phản hồi trên biểu đồ tĩnh
 Hình 15.8 Sửa đổi trong biểu đồ chờ

tới obs4 (tin nhắn TRUY VẤN2,4()), trong khi obs3 chuyển tiếp nó tới obs1 và obs4 (tin
nhắn TRUY VẤN3,1() và TRUY VẤN3,4 ()). Vì nó không thể mở rộng quá trình truyền tải,
obs4 sẽ gửi lại tin nhắn TRẢ LỜI() mỗi khi nó nhận được một truy vấn (tin nhắn TRẢ
LỜI 4.2() và TRẢ LỜI 4.3 ()). Vì nó đã được truy cập bởi quá trình truyền tải mạng, obs1 sẽ
gửi bằng cách trả lại tin nhắn TRẢ LỜI 1.3 () khi nó nhận được TRẢ LỜI 3,1 (). Khi mỗi
obs2 và obs3 nhận được tất cả các câu trả lời phù hợp với truy vấn của nó, nó sẽ gửi một
tin nhắn TRẢ LỜI() tới obs1. Cuối cùng, khi obs1 nhận được câu trả lời từ obs2 và obs3,
quá trình truyền tải mạng có phản hồi sẽ chấm dứt.
Truyền tải mạng với phản hồi trên biểu đồ truyền thông động có hướng Bây giờ
chúng ta hãy xem xét rằng tại thời điểm τ1, đồ thị có hướng ở bên trái của Hình 15.8 là đồ
thị chờ hiện tại của phép tính bốn quá trình tương ứng. Điều này có nghĩa là, tại τ1,
dep_set1 = {2,3} , dep_set2 = {4} , dep_set3 = {1,4} , và dep_set4 = ∅ (do đó p1, p2 và p3 bị
chặn, trong khi p4 đang hoạt động). Hơn nữa, các kênh đều không có tin nhắn ứng dụng.
Chúng ta hãy xem xét kịch bản sau đây. Quá trình p4 trước tiên gửi tin nhắn m đến p2 và
sau đó bắt đầu chờ tin nhắn từ p2. Thông báo m sẽ kích hoạt lại p2 và biểu đồ chờ (là một
công cụ khái niệm) được sửa đổi ngay lập tức. Điều này được mô tả trong Hình 15.8,
trong đó đồ thị có hướng ở phía bên trái là đồ thị chờ tại thời điểm τ1, tức là ngay trước
khi p4 gửi tin nhắn đến p2 và bắt đầu chờ tin nhắn từ quá trình này, trong khi đồ thị trên
bên phải là biểu đồ chờ tại thời điểm τ2, ngay sau khi p4 thực hiện các câu lệnh này.
Sau khi p2 được kích hoạt lại bởi tin nhắn ứng dụng m, nó sẽ gửi một tin nhắn và bắt đầu
chờ tin nhắn từ quá trình này. Gọi τ3 là thời điểm ngay sau khi việc này được thực hiện.
Việc sửa đổi tương ứng của biểu đồ chờ được chỉ ra ở cuối Hình 15.8.
Cuối cùng chúng ta hãy xem xét rằng obs1 khởi chạy truyền tải mạng với phản hồi tại
thời điểm τ1. Truyền tải mạng này, được mô tả trong hình 15.9, hoàn toàn giống với mô tả
trong hình 15.7. Chúng ta hãy nhớ lại rằng, như đã chỉ ra trước đây, một người quan sát
obsi chỉ truyền tải mạng nếu pi thụ động. Trong kịch bản được mô tả, mặc dù các thông
báo ứng dụng m và m được trao đổi bởi p4 và p2, nhưng các thông báo điều khiển vẫn
được bất kỳ người quan sát obsi nào nhận được trong khi quá trình pi liên quan đến nó là
thụ động. Do đó, quá trình truyền tải mạng có phản hồi chấm dứt và obs1 kết luận sai rằng
p1 có liên quan đến bế tắc.

Hình 15.9 Quan sát không nhất quán của biểu đồ chờ động

Quan sát xem các quy trình có bị động liên tục không Quan sát sai lầm xuất phát từ
thực tế là có hoạt động xử lý ở phía sau quá trình truyền tải mạng và quá trình truyền tải
mạng đã bỏ lỡ nó. Chúng ta hãy quan sát rằng thuộc tính FIFO của các kênh không đủ để
giải quyết vấn đề (trong Hình 15.9 tất cả các kênh đều hoạt động như các kênh FIFO).
Một cách đơn giản để giải quyết vấn đề này bao gồm việc yêu cầu mỗi người quan sát
obsi quan sát xem liệu quy trình pi của nó có tiếp tục thụ động trong khoảng thời gian nó
được truy cập bởi mạng truyền tải hay không (nhận được thông báo đầu tiên TRUY
VẤN() từ người quan sát obsj) và thời gian nó đã gửi tin nhắn TRẢ LỜI() tới người quan
sát này obsj. Như được minh họa bằng thuật toán sau đây, giá trị Boolean quan sát này
cộng với thực tế là các kênh là FIFO cho phép quan sát phân tán nhất quán về tính toán.
Đối với các kênh có liên quan, chúng ta hãy lưu ý rằng, nếu các kênh không phải là
FIFO thì việc quan sát sai có thể xảy ra, bất chấp các giá trị Boolean trước đó. Để thấy
điều này, chỉ cần xem xét trường hợp trong Hình 15.9, thông báo m được p4 gửi đến p2
đến sau thông báo điều khiển TRẢ LỜI() được gửi bởi obs4 tới obs2.