When a process of the application c

When a process of the application calls MPIX_COMM_REVOKE (similar operations exist for windows and files, we will, without loss of generality, reason in the case of communicators), all other alive processes in the communicator eventually receive a notification. The MPIX_COMM_REVOKE call has an effect on the entire scope of the communicator, without requiring a collective or matching call at any participant. Instead, the effect of the Revoke operation is observed at other processes during non-matching MPI communication calls: when receiving this notification, any communication on the communicator (ongoing or future) is interrupted and a special error code returned. Then, all surviving processes can safely enter the recovery procedure of the application, knowing that no alive process belonging to that communicator will deadlock as a result. After a communicator has been revoked, its state is definitively altered and it can never be used again to communicate. This alteration is not to be seen as the (direct) consequence of a failure, but as the consequence of the user explicitly calling a specific operation on the communicator. In a sense, Revoking a communicator explicitly achieves the
propagation of failure knowledge that has intentionally not been required, but is provided when the user deems necessary. Because the object is discarded definitively, any stale message matching the revoked object is appropriately ignored without modifications in the matching logic, and multiple processes may simultaneously Revoke the same communicator without fears of injecting delayed Revoke notifications, thereby interfering with post-recovery operations.
In order to restore communication capacity, ulfm provides the repair function MPIX_COMM_SHRINK, which derives new, fresh communicators that do not risk intermixing with prefailure operations or delayed notifications.

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

เมื่อกระบวนการของแอพลิเคชันเรียก MPIX_COMM_REVOKE (คล้ายอยู่สำหรับ windows และแฟ้ม เราจะ โดยไม่สูญเสียทั่วไป เหตุผลในกรณีเสนอ), กระบวนการอื่น ๆ ชีวิตใน communicator ที่ในที่สุดได้รับการแจ้งเตือน โทร MPIX_COMM_REVOKE มีผลต่อขอบเขตทั้งหมดของ communicator โดยไม่ต้องมีการเรียกรวม หรือตรงที่ร่วมการแข่งขัน แทน ข้อสังเกตผลของการดำเนินการยกเลิกที่อื่น ๆ กระบวนการการสนทนาสื่อสาร MPI ที่ไม่ตรงกัน: เมื่อได้รับการแจ้งเตือนนี้ มีการขัดจังหวะการสื่อสารในกระบวนการ communicator (อย่างต่อเนื่อง หรือในอนาคต) และส่งกลับรหัสข้อผิดพลาดพิเศษ แล้ว กระบวนการรอดตายทั้งหมดอย่างปลอดภัยสามารถป้อนการกู้คืนโปรแกรมประยุกต์ รู้ว่า กระบวนการไม่มีชีวิตเป็นของ communicator ที่จะการชะงักงันเป็นผล หลังจากที่ถูกเพิกถอนการ communicator อื่น ๆ มีการเปลี่ยนแปลงสถานะ และมันไม่เคยใช้อีกในการสื่อสาร เปลี่ยนแปลงนี้จะไม่ได้ เป็นผลของความล้มเหลว (โดยตรง) แต่ เป็นผลของผู้ใช้เรียกการดำเนินการเฉพาะบนกระบวนการ communicator อย่างชัดเจน ในความรู้สึก การยกเลิกการ communicator อย่างชัดเจนทำให้การเผยแพร่ความรู้ล้มเหลวที่ไม่ตั้งใจได้จำเป็น แต่ให้ไว้เมื่อผู้ใช้เห็นว่าจำเป็น เนื่องจากวัตถุจะถูกยกเลิกแน่นอน อย่างเหมาะสมละเว้นข้อความเก่าแล้วตรงกับวัตถุถูกเพิกถอน โดยไม่มีการปรับเปลี่ยนในตรรกะตรงกัน และกระบวนการที่หลายอาจพร้อมกัน ยกกระบวน communicator เดียวกันโดยไม่ต้องกลัวของการฉีดการแจ้งถอนล่าช้า จึง มีการกู้คืนหลังการผลิตสื่อสาร ulfm มีฟังก์ชันการซ่อมแซม MPIX_COMM_SHRINK ที่มาเสนอใหม่ สดเสี่ยงการ intermixing งาน prefailure หรือแจ้งล่าช้า

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

เมื่อกระบวนการของโปรแกรมเรียก MPIX_COMM_REVOKE (การดำเนินงานคล้ายกันอยู่สำหรับ Windows และไฟล์เราจะไม่มีการสูญเสียของทั่วไปเหตุผลในกรณีของการสื่อสาร) ในกระบวนการมีชีวิตอื่น ๆ ทั้งหมดใน Communicator ในที่สุดได้รับการแจ้งเตือน โทร MPIX_COMM_REVOKE มีผลต่อขอบเขตทั้งหมดของ Communicator ให้โดยไม่ต้องมีการเรียกรวมหรือการจับคู่ที่มีส่วนร่วมใด ๆ แต่ผลของการดำเนินการเพิกถอนการเป็นที่สังเกตในกระบวนการอื่น ๆ ในช่วงที่ไม่มีคู่ MPI สายการสื่อสาร: เมื่อได้รับการแจ้งเตือนนี้การสื่อสารใด ๆ บน Communicator ให้ (ต่อเนื่องหรือในอนาคต) ถูกขัดจังหวะและรหัสข้อผิดพลาดกลับพิเศษ จากนั้นทุกกระบวนการที่รอดตายได้อย่างปลอดภัยสามารถเข้าสู่ขั้นตอนการฟื้นตัวของแอพลิเคชันที่รู้ว่าไม่มีกระบวนการมีชีวิตที่อยู่ใน Communicator ที่จะหยุดชะงักเป็นผล หลังจากที่มีการสื่อสารที่ได้รับการเพิกถอนสถานะของมันคือการเปลี่ยนแปลงอย่างแน่นอนและไม่สามารถนำมาใช้อีกครั้งในการสื่อสาร การเปลี่ยนแปลงนี้ไม่ได้ที่จะถูกมองว่าเป็น (โดยตรง) ผลที่ตามมาของความล้มเหลว แต่เป็นผลมาจากการใช้อย่างชัดเจนเรียกการดำเนินการเฉพาะใน Communicator ให้ ในความรู้สึกเพิกถอน Communicator อย่างชัดเจนประสบความสำเร็จใน
การขยายพันธุ์ของความรู้ความล้มเหลวที่มีเจตนาไม่ได้จำเป็น แต่มีให้เมื่อผู้ใช้เห็นว่าจำเป็น เพราะวัตถุที่ถูกทิ้งแตกหักข้อความเก่าที่ตรงกับวัตถุเพิกถอนจะถูกละเว้นเหมาะสมโดยไม่ต้องแก้ไขในตรรกะที่ตรงกันและกระบวนการหลายคนพร้อมกันอาจเพิกถอน Communicator เดียวกันโดยไม่ต้องกลัวว่าจะฉีดแจ้งเตือนยกเลิกล่าช้าจึงรบกวนกับการดำเนินงานหลังการกู้คืน.
ใน เพื่อเรียกคืนความจุสื่อสาร ulfm ให้ MPIX_COMM_SHRINK ฟังก์ชั่นการซ่อมแซมซึ่งมาใหม่การสื่อสารใหม่ที่ไม่ต้องเสี่ยงกับการดำเนินงาน intermixing prefailure หรือการแจ้งเตือนล่าช้า