If the communication pattern is com

If the communication pattern is complex, the occurrence of failures has the potential to deeply disturb the application and prevent an effective recovery from being implemented.
Consider the example in Figure 1: as long as no failure occurs, the processes are communicating in a point-to-point pattern (called plan A). Process Pk is waiting to receive a message from Pk−1, then sends a message to Pk+1 (when such processes exist). Let’s observe the effect of introducing a failure in plan A, and consider that P1 has failed. As only P2 communicates directly with P1, other processes do not detect this condition, and only P2 is informed of the failure of P1. The situation at P2 now raises a dilemma: P3 waits on P2, a non-failed process, therefore the operation must block until the matching send is posted at P2; however, P2 knows that P1 has failed, and that the application should branch into its recovery procedure plan B ; if P2 were to switch abruptly to plan B, it would cease matching the receives P3 posted following plan A. At this point, P2 needs an effective way of interrupting operations that it does not intend to match anymore, otherwise, the application would reach a deadlock: the messages that P3 to Pn are waiting for will never arrive. The proposed solution to resolve this scenario is that, before switching to plan B, the user code in P2 calls MPIX_COMM_REVOKE, a new API which notifies all other processes in the communicator that a condition requiring
recovery actions has been reached. Thanks to this flexibility, the cost associated with consistency in error reporting is paid only after an actual failure has happened, and only
when necessary to the algorithm, and applications that do not need consistency, or in which the user can prove that the communication pattern remains safe, can enjoy better recovery performance.

ผลลัพธ์ (ไทย) 1:

ถ้ารูปแบบการสื่อสารมีความซับซ้อน ความล้มเหลวที่เกิดขึ้นมีศักยภาพในการรบกวนโปรแกรมอย่างลึกซึ้ง และป้องกันการกู้คืนที่มีประสิทธิภาพจากการดำเนินการพิจารณาตัวอย่างในรูปที่ 1: ตราบเท่าที่ไม่ขัดข้อง กระบวนการจะสื่อสารในรูปแบบจุดต่อจุด (เรียกว่าแผน A) กระบวนการ Pk รอรับข้อความจาก Pk−1 แล้วส่งต่อข้อความไป Pk + 1 (เมื่อกระบวนการดังกล่าวมีอยู่) ลองสังเกตเห็นผลของการแนะนำความล้มเหลวในแผน A และพิจารณาว่า ล้มเหลว P1 P2 เท่านั้นการสื่อสารโดยตรงกับ P1 อื่น ๆ กระบวนการตรวจสอบเงื่อนไขนี้ และทราบของความล้มเหลวของ P1 P2 เท่านั้น สถานการณ์ที่ P2 ตอนยกคายไม่ออก: P3 รอใน P2 กระบวนการไม่ใช่ล้มเหลว ดังนั้น การดำเนินการต้องบล็อคจนส่งตรงลงที่ P2 อย่างไรก็ตาม P2 รู้ว่า P1 ล้มเหลว และว่า โปรแกรมประยุกต์ควรสาขาเป็นการวางแผนขั้นตอนกู้คืน B ถ้า P2 จะ เปลี่ยนทันทีแผน B มันจะหยุดตรงรับ P3 โพสต์ต่อแผนก. ที่จุดนี้ P2 ต้องวิธีที่มีประสิทธิภาพของการขัดจังหวะการดำเนินการที่ไม่ได้ตั้งใจให้ตรงกับอีกต่อไป หรือ แอพลิเคชันจะถึงตาย: ข้อความที่รอ P3 กับหมายเลขสินค้าจะเข้ามาไม่ นำเสนอเพื่อแก้ไขสถานการณ์นี้เป็นที่ เปลี่ยนแผน B รหัสผู้ใช้ใน P2 โทร MPIX_COMM_REVOKE, API ใหม่ซึ่งจะแจ้งให้ทราบกระบวนการอื่น ๆ ทั้งหมดใน communicator ที่ที่จำเป็นต้องมีเงื่อนไขการดำเนินการกู้คืนแล้ว ด้วยความยืดหยุ่นนี้ ต้นทุนที่เกี่ยวข้องกับความสม่ำเสมอในการรายงานข้อผิดพลาดจะชำระหลัง จากความล้มเหลวที่แท้จริงที่เกิดขึ้น และเท่านั้นเมื่อจำเป็นอัลกอริทึม และโปรแกรมประยุกต์ที่ไม่จำเป็นต้องสอดคล้อง หรือที่ผู้ใช้สามารถพิสูจน์ว่า รูปแบบการสื่อสารยังคงปลอดภัย สามารถเพลิดเพลินไปกับประสิทธิภาพการกู้คืน

ผลลัพธ์ (ไทย) 2:

หากรูปแบบการสื่อสารที่มีความซับซ้อนที่เกิดขึ้นจากความล้มเหลวมีศักยภาพที่จะรบกวนลึกใบสมัครและป้องกันไม่ให้มีการกู้คืนที่มีประสิทธิภาพจากการดำเนินการ.
พิจารณาตัวอย่างในรูปที่ 1: ตราบใดที่ไม่มีความล้มเหลวที่เกิดขึ้นกระบวนการที่มีการติดต่อสื่อสารใน point- รูปแบบไปยังอีกจุด (เรียกว่าแผน A) กระบวนการ PK ก็รอคอยที่จะได้รับข้อความจาก PK-1 แล้วส่งข้อความไปยัง Pk + 1 (เมื่อกระบวนการดังกล่าวอยู่) ลองสังเกตผลของการแนะนำความล้มเหลวในการวางแผน A a และพิจารณาว่า P1 ล้มเหลว ในฐานะที่เป็นเพียง P2 สื่อสารโดยตรงกับ P1 กระบวนการอื่น ๆ ไม่ได้ตรวจสอบสภาพนี้และมีเพียง P2 จะแจ้งให้ทราบถึงความล้มเหลวของ P1 สถานการณ์ในตอนนี้ P2 ทำให้เกิดภาวะที่กลืนไม่เข้าคายไม่ออก: P3 รอใน P2 เป็นกระบวนการที่ไม่ล้มเหลวดังนั้นการดำเนินการจะต้องปิดกั้นจนส่งตรงกับที่มีการโพสต์ที่ P2; แต่รู้ว่า P2 P1 ล้มเหลวและที่สมัครควรสาขาเข้าไปในการกู้คืนแผนขั้นตอนการข; ถ้า P2 จะเปลี่ยนทันทีเพื่อ Plan B ก็จะหยุดที่ตรงกับที่ได้รับ P3 โพสต์ตามแผนก ณ จุดนี้ P2 ต้องการวิธีที่มีประสิทธิภาพในการขัดขวางการดำเนินงานว่ามันไม่ได้ตั้งใจที่จะตรงกับอีกต่อไปมิฉะนั้นโปรแกรมจะเข้าถึง การหยุดชะงัก: ข้อความที่ P3 จะ Pn กำลังรอจะไม่มาถึง วิธีการแก้ปัญหาที่นำเสนอในการแก้ไขสถานการณ์นี้ก็คือว่าก่อนที่จะเปลี่ยน Plan B, รหัสของผู้ใช้ใน P2 เรียก MPIX_COMM_REVOKE, ใหม่ API ซึ่งจะแจ้งให้กระบวนการอื่น ๆ ทั้งหมดใน Communicator ที่เป็นเงื่อนไขที่กำหนดให้
การดำเนินการกู้คืนที่ได้รับถึง ขอบคุณที่มีความยืดหยุ่นนี้ค่าใช้จ่ายที่เกี่ยวข้องกับความสม่ำเสมอในการรายงานข้อผิดพลาดจะจ่ายเฉพาะหลังจากความล้มเหลวที่เกิดขึ้นจริงที่เกิดขึ้นและมีเพียง
เมื่อมีความจำเป็นที่จะอัลกอริทึมและการใช้งานที่ไม่จำเป็นต้องสอดคล้องหรือที่ผู้ใช้สามารถพิสูจน์ได้ว่ารูปแบบการสื่อสาร ยังคงปลอดภัยสามารถเพลิดเพลินกับประสิทธิภาพการทำงานที่ดีกว่าการกู้คืน

ผลลัพธ์ (ไทย) 3:

ถ้ารูปแบบการสื่อสารที่ซับซ้อน , การเกิดความล้มเหลว มีศักยภาพที่จะรบกวนการดูดและป้องกันการกู้คืนที่มีประสิทธิภาพจากการใช้พิจารณาตัวอย่างในรูปที่ 1 : ตราบใดที่ไม่มีความล้มเหลวเกิดขึ้น กระบวนการสื่อสารในรูปแบบจุด ( เรียกว่าวางแผน ) คือกระบวนการรอที่จะได้รับข้อความจาก PK − 1 แล้วส่งข้อความถึง PK + 1 ( เมื่อกระบวนการดังกล่าวอยู่ ) เรามาดูผลของการล้มเหลวในการวางแผน และพิจารณาว่า P1 ล้มเหลว เป็นเพียง P2 สื่อสารโดยตรงกับ P1 , กระบวนการอื่น ๆไม่พบสภาพเช่นนี้ และเฉพาะ P2 ทราบของความล้มเหลวของ P1 . สถานการณ์ที่กลืนไม่เข้าคายไม่ออก : P3 P2 ตอนนี้ยกคอย P2 ไม่ล้มเหลวในกระบวนการ ดังนั้นการผ่าตัดต้องบล็อก จนถึงการจับคู่ส่งโพสต์ที่ P2 ; อย่างไรก็ตาม , P1 P2 รู้ว่าล้มเหลว และที่สมัครควรสาขาในการกู้คืนของกระบวนการแผน B ; ถ้า P2 จะสลับชะงักแผน B ก็จะหยุดจับคู่ได้รับ P3 โพสต์ตามแผน . ณจุดนี้ , P2 ต้องการวิธีที่มีประสิทธิภาพของการขัดจังหวะที่ไม่คิดจะแข่งอะไรแล้ว มิฉะนั้นโปรแกรมจะเจอทางตัน : ข้อความที่ P3 เพื่อเตรียมรอจะไม่มีวันมาถึง เสนอโซลูชั่นเพื่อแก้ไขสถานการณ์นี้คือ ก่อนที่จะเปลี่ยนเป็นแผน B ผู้ใช้รหัสลงไปในโทรศัพท์ mpix_comm_revoke , ใหม่ API ซึ่งแจ้งกระบวนการอื่น ๆในระบบที่สภาวะที่ต้องการการดำเนินการกู้คืนได้ถึง ขอขอบคุณความยืดหยุ่นนี้ ต้นทุนที่เกี่ยวข้องกับความสอดคล้องในการรายงานข้อผิดพลาดจะจ่ายหลังจากความล้มเหลวที่แท้จริงเกิดขึ้น และเพียงเมื่อจำเป็นต้องอัลกอริทึมและการประยุกต์ใช้ที่ไม่ต้องการความสอดคล้อง หรือที่ผู้ใช้สามารถพิสูจน์ว่ารูปแบบการสื่อสารยังคงปลอดภัย สามารถเพลิดเพลินกับประสิทธิภาพการฟื้นตัวดีขึ้น