Professional Documents
Culture Documents
Chương 15.4, 15.4.1
Chương 15.4, 15.4.1
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.