A resource pool-based nccl migration method

Abstract

The application discloses an NCCL migration method based on a resource pool, relates to the technical field of high-performance computing communication optimization, and comprises the following steps: obtaining thread identification records, synchronization timestamp markers and thread state information from the resource pool by scanning the multithread running environment of the NCCL communication program based on the resource pool at a source end; generating a thread state snapshot in combination with data packet transmission progress, constructing a data transmission state file containing transmission interruption recovery points and synchronization signal priorities, and determining an initialized synchronization marker data set; transmitting the thread state snapshot and a data check code value to a target end according to the initialized synchronization marker data set, decoding the synchronization marker by using an inheritance marker analysis rule, generating a control module state cache of the target end, and obtaining a preliminary synchronization marker inheritance result; and the NCCL migration method based on the resource pool significantly improves the migration efficiency, data link continuity and overall running stability of the NCCL communication program in a high-load scene.

Description

Technical Field

[0001] This invention relates to the field of high-performance computing communication optimization technology, and specifically to an NCCL migration method based on resource pools. Background Technology

[0002] In multi-threaded resource management scenarios of high-performance communication programs, a unique and complex technical problem arises: how to achieve efficient coordination between diverse address allocation of resource pools and thread synchronization control, especially ensuring lossless restoration and dynamic adjustment of address mapping relationships during cross-device migration. Specifically, the communication program needs to pre-allocate a resource pool containing various address types for each processing device during the initialization phase. These address types cover shared memory, point-to-point communication, long and short intervals of driver memory, mapped addresses, and network communication, among others. The resource pool design is further divided into multiple sub-pool structures, with resource blocks divided at fixed intervals and independently indexed. Simultaneously, it needs to dynamically select between short-interval or long contiguous address spaces for resource allocation based on the request interval. In this context, the challenge lies in ensuring the atomicity and consistency of resource pool allocation in a multi-threaded environment, avoiding address resource allocation conflicts caused by thread contention. Furthermore, when a control module is implanted in the user thread to intercept communication interface operations and monitor synchronization status, how to handle the synchronization flag marking and reporting delays after asynchronous operations are completed, ensuring that the migration control thread can accurately detect the synchronization completion signals of all threads. Furthermore, during cross-device migration, if the communication topology of the target device differs from that of the source device, the resource pool needs to dynamically adjust the address mapping relationship. This adjustment may result in some address resources not being directly reusable. How to accurately reconstruct the target device's resource pool and complete the mapping adjustment while preserving the source device's context data, and simultaneously verify the consistency of the mapping relationship, has become a pressing problem. This issue not only involves fine-grained management of the resource pool but also complex interactions involving multi-threaded synchronization, migration control, and address mapping, directly impacting the stability and migration efficiency of the communication program under high load scenarios. Summary of the Invention

[0003] The purpose of this invention is to provide a resource pool-based NCCL migration method to solve the problems existing in the prior art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: an NCCL migration method based on a resource pool, comprising the following steps: S1. By scanning the multi-threaded runtime environment of the NCCL communication program based on the resource pool at the source end, obtain thread identification records, synchronization timestamp markers and thread state information from the resource pool; generate thread state snapshots in combination with data packet transmission progress, construct a data transmission state file containing transmission interruption recovery points and synchronization signal priorities, and determine the initialized synchronization marker dataset; S2. Based on the initialized synchronization mark dataset, transmit the thread state snapshot and data check code value to the target end, decode the synchronization mark using the inheritance mark parsing rules, generate the control module state cache of the target end, and obtain the preliminary synchronization mark inheritance result. S3. Based on the preliminary synchronization mark inheritance results, adjust the thread lock resource status in the target control module's state cache according to the synchronization mark update frequency and state transition triggering conditions, handle mark conflicts in conjunction with inheritance conflict resolution logic, and determine the updated state consistency verification results. S4. Based on the state consistency verification results, obtain the target end module state log records and module resource occupancy table, match the source end synchronization signal priority and transmission interruption recovery point, remap the target end communication address resources, and obtain the adjusted communication topology adaptation scheme.

[0005] Preferably, step S1 includes scanning the multi-threaded runtime environment of the source-end NCCL communication program based on a resource pool, obtaining thread identifier records, synchronization timestamp markers, and thread state information from the resource pool. The resource pool contains multiple types of address blocks, such as shared memory addresses, long and short interval GPU memory segments, P2P communication addresses, and network mapping addresses used for NCCL communication, and is divided into multiple independently indexable sub-pools at fixed intervals. The sub-pool division process involves uniformly dividing the overall address space of the resource pool into fixed-size blocks, assigning a specific type of address to each block to support independent access, thus obtaining a set of thread state information. For the set of thread state information, a thread state snapshot is generated in conjunction with the data packet transmission progress. The thread state snapshot captures dynamic changes by recording the current transmission position and interruption points. The process of capturing dynamic changes involves comparing the difference between the transmission progress and the timestamp markers to identify the change points. Identify the transmission interruption recovery point; starting from the transmission interruption recovery point, construct a data transmission status file containing the transmission interruption recovery point and synchronization signal priority. The construction process involves integrating the recovery point and priority data into a structured file format that supports fast querying. This integration into a structured file format involves matching each recovery point to a priority value to form key-value pairs, thus obtaining the data transmission status file. Obtain the synchronization signal priority in the data transmission status file and sort it by priority using the sub-pool independent index. The sorting process uses a preset threshold to compare each priority value to determine the order. If the priority is higher than the threshold, it is placed at the front, resulting in a sorted priority sequence. Based on the sorted priority sequence, merge the network mapping address and P2P communication address to generate initialization markers. The generation process involves mapping the address to the corresponding position in the sequence to form a complete dataset, thus determining the initialization synchronization marker dataset.

[0006] Preferably, step S2 includes obtaining thread state snapshots and data checksum values ​​from an initialized synchronization marker dataset, sending the thread state snapshots and data checksum values ​​through the target end transmission process to obtain a set of snapshots after transmission; for the set of snapshots after transmission, decoding the synchronization markers using inheritance marker parsing rules, wherein the inheritance marker parsing rules perform bit-by-bit matching by comparing the marker bit sequence to generate a control module state cache at the target end, obtaining decoded cache data; based on the decoded cache data, dynamically adjusting the checksum by fusing a preset priority sorting sequence, wherein the dynamic adjustment of the checksum is performed by adding or subtracting to correct the difference between the checksum value and the priority value, to determine the adjusted priority sequence; and verifying cache consistency by combining the adjusted priority sequence with the initialized marker fusion, wherein the initialized marker fusion performs consistency verification by merging the marker dataset with the corresponding items in the sequence to obtain a preliminary synchronization marker inheritance result.

[0007] Preferably, step S3 includes obtaining the update frequency value and state transition trigger condition from the initial synchronization mark inheritance result; performing a matching operation by comparing the update frequency value with a preset threshold to obtain a frequency matching set; adjusting the thread lock resource state in the target control module state cache according to the state transition trigger condition for the frequency matching set; generating adjusted lock state data by comparing the lock resource state with the allocation threshold for verification; obtaining the adjusted lock state data; handling mark conflicts by combining inheritance conflict resolution logic; if the conflict value exceeds a preset threshold, performing priority sequence correction; determining the conflict handling sequence by comparing the conflict value with the sequence item; decoding the synchronization mark by fusing the conflict handling sequence with the parsing rules; the parsing rules generate an updated control module state cache by matching the mark bit sequence bit by bit to obtain a cache update set; performing a consistency check on the cache update set; comparing the fused data check code value with the initialization mark to determine the updated state consistency check result.

[0008] Preferably, step S4 includes obtaining module status log records and module resource occupancy tables from the target module based on the status consistency verification result. The status consistency verification is performed by comparing the differences between the source and target module parameters. If the difference is less than a preset threshold, the verification is considered successful. The module status log records are used to record the module's operating history, and the module resource occupancy tables are used to display resource usage. For the module status log records and module resource occupancy tables, the synchronization signal priority and transmission interruption recovery point of the source end are matched. The synchronization signal priority is sorted according to the urgency of the signal, and the transmission interruption recovery point is restored by recording the interruption position, resulting in a matched priority sequence.

[0009] Preferably, step S4 further includes remapping the target end communication address resources according to the matched priority sequence. The remapping adopts an address reallocation method to convert the old address into a new address to optimize the connection. An abnormal state repair service is introduced to repair potential faults by analyzing the module status log records and determine the mapped address configuration. From the mapped address configuration, an adjusted communication topology adaptation scheme is constructed. The communication topology adaptation scheme integrates address resources and priorities, introduces a dynamic priority adjustment service to modify priorities according to real-time load, and determines that if the load exceeds a threshold, low-priority signals are reduced to obtain a preliminary adaptation scheme. The preliminary adaptation scheme is obtained and finally verified. The stability of the preliminary adaptation scheme is tested by simulated transmission to obtain the adjusted communication topology adaptation scheme.

[0010] Preferably, the method further includes S5: according to the adjusted communication topology adaptation scheme, loading the initial configuration of the target end communication interface, verifying the accuracy of the address mapping by combining the data checksum value, and if the verification result shows inconsistency, triggering the resource distribution reallocation process to determine the final communication interface operating environment. Specifically, this includes obtaining the backup address pool from the target end according to the topology adaptation scheme, loading the initial configuration of the communication interface, verifying the accuracy of the address mapping by comparing the code value before and after mapping by combining the data checksum value, and obtaining the verification result; if the verification result shows inconsistency, extracting spare resources from the backup address pool, triggering the resource distribution reallocation process, and determining the address configuration after reallocation by adjusting the resource allocation ratio.

[0011] Preferably, step S5 further includes obtaining the redistributed address configuration, integrating redundant links in the backup address pool, constructing backup paths for the communication interface by prioritizing links, and obtaining a path integration configuration; from the path integration configuration, applying the adjusted communication topology adaptation scheme, merging redundant links, optimizing connections through path redundancy verification, and determining the final communication interface operating environment.

[0012] Preferably, it also includes S6: activating the target-side multi-threaded communication logic through the final communication interface runtime environment, updating the thread running parameters based on the state consistency verification result and module state log records, determining whether the seamless data link switching conditions are met, and obtaining the complete context migration state. Specifically, this includes obtaining the target-side multi-threaded communication logic from the interface runtime environment, activating the logic and integrating the state consistency verification result to obtain the activated communication logic; for the activated communication logic, updating the thread running parameters based on the module state log records, and determining the updated parameter set.

[0013] Preferably, step S6 further includes determining the data link switching conditions based on the updated parameter set and the verification results according to the preset switching threshold, and obtaining the switching condition satisfaction; obtaining the switching condition satisfaction, extracting migration resources from the backup thread pool, and constructing a complete migration configuration by integrating the context migration state; and using the complete migration configuration to optimize the target end activation mechanism and integrate the parameter update process to obtain the complete context migration state.

[0014] As can be seen from the above technical solution, the present invention has the following beneficial effects: The present invention scans the multi-threaded runtime environment of the NCCL communication program built on a resource pool at the source end, obtains thread identifiers, timestamps, and status information in real time, and generates a status snapshot in conjunction with the data packet transmission progress, thus achieving accurate capture of multiple types of address resources before migration. This method utilizes the initial synchronization mark dataset and the inherited mark resolution mechanism to restore the thread state cache and resolve synchronization mark conflicts at the target end, effectively ensuring the consistency of multi-threaded states during the migration process. By remapping the target end's communication address resources based on the state consistency verification results, the present invention can adapt to the differences in topology between the source and target ends, establishing a dynamically adjusted communication topology adaptation scheme, thereby achieving lossless recovery of the address mapping relationship of complex resource pools.

[0015] Furthermore, this invention ensures the accuracy and stability of the target end communication interface initialization configuration by verifying the address mapping and implementing resource distribution redistribution strategies, enabling the migrated communication environment to reliably connect to multi-threaded logic and achieve seamless switching to the context running state of the new node.

[0016] In summary, this invention not only solves the problems of resource pool allocation conflicts caused by multi-threaded contention, asynchronous thread synchronization delays, and difficulties in address mapping reconstruction during cross-device migration, but also significantly improves the migration efficiency, data link continuity, and overall operational stability of NCCL communication programs under high-load scenarios. Attached Figure Description

[0017] Figure 1 This is a flowchart of the NCCL migration method based on resource pools according to the present invention.

[0018] Figure 2 This diagram illustrates how NCCL selects different data link types under different GPU topologies in existing technologies.

[0019] Figure 3 This is a schematic diagram of the NCCL migration structure of the present invention.

[0020] Figure 4 The diagram illustrates the resource allocation method. The left diagram shows the original resource allocation method of NCCL, and the right diagram shows the resource allocation method of the present invention.

[0021] Figure 5 This is a schematic diagram illustrating the specific modifications made to NCCL in this invention.

[0022] Figure 6 This is a schematic diagram of resource pool design method a of the present invention.

[0023] Figure 7 This is a schematic diagram of resource pool design method b of the present invention.

[0024] Figure 8 This is a schematic diagram of resource pool design method c of the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] like Figure 1 As shown, the present invention provides a technical solution: an NCCL migration method based on a resource pool, comprising the following steps: S1. By scanning the multi-threaded runtime environment of the NCCL communication program based on the resource pool at the source end, obtain thread identification records, synchronization timestamp markers and thread state information from the resource pool; generate thread state snapshots in combination with data packet transmission progress, construct a data transmission state file containing transmission interruption recovery points and synchronization signal priorities, and determine the initialized synchronization marker dataset; S2. Based on the initialized synchronization mark dataset, transmit the thread state snapshot and data check code value to the target end, decode the synchronization mark using the inheritance mark parsing rules, generate the control module state cache of the target end, and obtain the preliminary synchronization mark inheritance result. S3. Based on the preliminary synchronization mark inheritance results, adjust the thread lock resource status in the target control module's state cache according to the synchronization mark update frequency and state transition triggering conditions, handle mark conflicts in conjunction with inheritance conflict resolution logic, and determine the updated state consistency verification results. S4. Based on the state consistency verification results, obtain the target end module state log records and module resource occupancy table, match the source end synchronization signal priority and transmission interruption recovery point, remap the target end communication address resources, and obtain the adjusted communication topology adaptation scheme. S5. Based on the adjusted communication topology adaptation scheme, load the initial configuration of the target end communication interface, and verify the accuracy of the address mapping by combining the data check code value. If the verification results are inconsistent, trigger the resource distribution reallocation process to determine the final communication interface operating environment. S6. Through the final communication interface runtime environment, activate the multi-threaded communication logic of the target end, update the thread running parameters based on the state consistency verification result and module state log record, determine whether the seamless data link switching conditions are met, and obtain the complete context migration state.

[0027] In summary, this implementation utilizes a resource pool mechanism to scan the source-side NCCL multi-threaded communication environment. It constructs a complete thread state snapshot using thread identifier records, synchronization timestamps, and thread state information, enabling the migration process to capture communication interruption recovery points and synchronization signal priorities. The thread state snapshot and data checksum are decoded and uniformly loaded on the target side via inherited tag parsing rules, allowing the target side to build a preliminary control module state cache. To ensure that the communication state remains consistent with the source side after migration, the system adjusts thread lock resources based on the synchronization tag update frequency and state transition conditions. It also resolves tag conflicts between different threads through inheritance conflict resolution logic, obtaining updated state consistency verification results. Furthermore, based on the consistency verification results, combined with the target-side module state logs and resource usage, the system remaps communication address resources and matches the source-side synchronization signal priorities and interruption recovery points to generate a communication topology adaptation scheme suitable for the target side. After address remapping, the accuracy of the configuration is ensured by verifying the checksum. If a deviation is detected, a resource distribution reallocation process is initiated to build a stable communication interface operating environment. In the final runtime environment, the target end activates multi-threaded communication logic and updates thread running parameters based on consistency check results and module logs to determine whether the seamless link switching conditions are met, thus achieving complete context migration.

[0028] S1 involves scanning the multi-threaded runtime environment of the source-end NCCL communication program based on a resource pool, obtaining thread identifier records, synchronization timestamp markers, and thread state information from the resource pool. The resource pool contains various address blocks, including shared memory addresses for NCCL communication, long and short interval GPU memory segments, P2P communication addresses, and network mapping addresses. These blocks are then divided into multiple independently indexable sub-pools at fixed intervals. The sub-pool division process involves uniformly dividing the overall address space of the resource pool into fixed-size blocks, assigning each block a specific type of address to support independent access, thus obtaining a set of thread state information. For this set of thread state information, a thread state snapshot is generated based on the data packet transmission progress. This snapshot captures dynamic changes by recording the current transmission position and interruption points. The process of capturing dynamic changes involves comparing the difference between the transmission progress and the timestamp markers to identify change points and determine the transmission status. Transmission interruption recovery point; Starting from the transmission interruption recovery point, a data transmission status file containing the transmission interruption recovery point and synchronization signal priority is constructed. The construction process involves integrating the recovery point and priority data into a structured file format that supports fast querying. The integration into the structured file format is achieved by matching each recovery point to the priority value to form key-value pairs, thus obtaining the data transmission status file. The synchronization signal priority in the data transmission status file is obtained and sorted by priority using the sub-pool independent index. The sorting process uses a preset threshold to compare each priority value to determine the order. If the priority is higher than the threshold, it is placed in the front, resulting in a sorted priority sequence. Based on the sorted priority sequence, the network mapping address and P2P communication address are fused to generate initialization markers. The generation process involves mapping the address to the corresponding position in the sequence to form a complete dataset, thus determining the initialization synchronization marker dataset.

[0029] In this implementation, firstly, in the source-side multi-threaded runtime environment based on the resource pool, the resource pool is pre-configured to consist of multiple address blocks. Each address block has a clearly defined address range and purpose, specifically including shared memory addresses for inter-process communication, long-interval graphics processing unit (GPU) memory segments for storing communication buffer data, short-interval GPU memory segments for storing short-term, small-batch data, data peer-to-peer communication addresses for direct device-to-device transmission, and network mapping addresses for cross-node communication. The overall address space of the resource pool is sequentially divided into several fixed-size contiguous address blocks during initialization. The division is performed block by block according to a uniform size unit. After all blocks are sequentially divided from the starting address to higher addresses... These blocks are assigned one of the following types according to preset rules: shared memory address block, long-interval graphics processing unit memory segment address block, short-interval graphics processing unit memory segment address block, data peer-to-peer communication address block, and network mapping address block. Each type of address block is assigned a unique type number. These address blocks are then combined into multiple sub-pools at fixed intervals. Each sub-pool consists of several address blocks of the same or different types. Each sub-pool is assigned a unique sub-pool index number upon creation. The thread identifier is a unique integer number assigned to each thread participating in communication upon creation. This number corresponds one-to-one with the thread number in the operating system and is stored in the thread record table of the corresponding sub-pool in the resource pool.

[0030] Specifically, the synchronization timestamp is a time value recorded by each thread when performing a send or receive operation. This time value uses a unified time source and is recorded once at the beginning and end of each data packet transmission operation to represent the time order of the thread in the multi-threaded runtime environment. Thread state information includes whether the thread is currently in a running, waiting, or blocked state, the sub-pool index number of the address block currently associated with the thread, the type of the most recently completed transmission operation of the thread, and the shared memory address, graphics processing unit video memory segment address, data peer-to-peer communication address, or network mapping address used by that operation. The system iterates through the thread records in each sub-pool, reading the stored thread identifier record, synchronization timestamp, and the aforementioned thread state information one by one to form a thread state information set. After obtaining the thread state information set, the system starts to generate a thread state snapshot based on the data packet transmission progress. The data packet transmission progress is calculated by counting the number of successfully sent or received data packets by each thread. The percentage values ​​are obtained from the number of data bytes and the total number of bytes to be sent or received. At the same time, the sequence number of the current data packet in the continuous data stream and the upper limit of the number that has been transmitted are recorded. The current transmission position is represented by the percentage value and the sequence number. When a thread stops transmitting due to resource contention or network reasons, the difference between the synchronization timestamp at that moment and the synchronization timestamp at the end of the previous normal transmission is calculated. If the difference is greater than the allowable idle time value set for the thread in advance, it is determined that a transmission interruption has occurred between the two records. The system records the synchronization timestamp corresponding to the interruption moment, the data packet sequence number at that time, and the number of bytes transmitted in the data packet at that time as a change point. After all the change points are sorted in chronological order, the last change point is determined as the transmission interruption recovery point of the thread. This recovery point indicates that when the thread resumes at the target end, it should continue transmission from the data packet sequence number and the number of bytes transmitted.After obtaining the transmission interruption recovery point for each thread, the system begins constructing a data transmission status file. This file uses a structured file format, with each record corresponding to a recovery record for a single thread. Each record includes the thread's identifier, the subpool index number of the thread's subpool, the timestamp of the thread's transmission interruption recovery point, the sequence number of the data packet corresponding to that recovery point, the number of bytes already transmitted for that recovery point, and the thread's synchronization signal priority. The synchronization signal priority is calculated based on the thread's importance and real-time requirements. This calculation process involves first assigning a basic importance level to each thread, based on the thread's processing... The types of data and their roles in the communication process are determined. For example, threads responsible for transmitting control information are assigned a higher priority, while threads responsible for transmitting large volumes of non-control data are assigned a relatively lower priority. Then, a real-time weight is assigned to each thread based on the number of transmission failures and interruptions in a recent period. A higher number of transmission failures and interruptions indicates a higher sensitivity to recovery, and its real-time weight is set to a higher level. The basic importance level and the real-time weight are added together to obtain the synchronization signal priority value. When the system writes the data transmission status file to the storage medium, it saves each record's transmission interruption recovery point and synchronization signal priority value in pairs, ensuring that each recovery point corresponds to a specific priority value, thus forming a key-value pair relationship.

[0031] Furthermore, after the data transmission status file is constructed, the system reads all synchronization signal priority values ​​from the file and sorts them by priority based on their corresponding sub-pool index numbers. During sorting, all records in the data transmission status file are first grouped by sub-pool index number. Within each group, records are arranged in descending order of synchronization signal priority values. To distinguish high-priority records from low-priority records, the system calculates a threshold for each group. The threshold is determined as follows: all synchronization signal priority values ​​within the group are arranged in ascending order, and the priority value at the middle position of the arrangement is taken as the threshold for that group. When the number of records in a group is even, the higher of the two middle values ​​is taken as the threshold; when the number of records in a group is odd, the value corresponding to the middle position is taken as the threshold. This ensures that approximately half of the records in each group have priority values ​​no lower than the threshold. During actual sorting, the system ensures that the priority values ​​are not lower than the threshold. Records with priority values ​​above the threshold are placed at the beginning of the group, while records with priority values ​​below the threshold are placed at the end of the group, forming a sorted priority sequence. In the sorted priority sequence, the position of each record also reflects its relative priority in its respective sub-pool. After obtaining the sorted priority sequence, the system uses the sub-pool index number stored in each record to find the pre-registered network mapping address and data peer communication address in the corresponding sub-pool. The system then maps the network mapping address and data peer communication address of each record to the corresponding positions according to the record's position in the priority sequence. This creates sequential entries in the initialization tag data structure. Each sequential entry includes a thread identifier record, a sub-pool index number, a transmission interruption recovery point, a synchronization signal priority value, a network mapping address, and a data peer communication address. The order of the entries is completely consistent with the sorted priority sequence. This set of entries constitutes a complete dataset, which is the initialized synchronization tag dataset.

[0032] In the above process, the thread identifier record represents the unique identity of the thread, the sub-pool index number represents the location of the address resource used by the thread in the sub-pool, the synchronization timestamp represents the time order of the thread in the multi-threaded environment, the thread state information represents the current running state and resource usage of the thread, the data packet transmission progress represents the degree of completion of data transmission processed by the thread, the current transmission position and the interruption point together represent the actual stopping position during transmission, the transmission interruption recovery point represents where to resume transmission at the target end, the data transmission status file is a structured file that stores the above information, the synchronization signal priority value is an integer that measures the importance of synchronization and real-time requirements, the threshold is the boundary value that distinguishes high-priority records from low-priority records in each sub-pool, the sorted priority sequence is the record order after rearranging according to priority, the network mapping address and data peer communication address are the specific address data used for subsequent migration and reconstruction of communication paths, and the initialized synchronization mark dataset is the complete data foundation used at the target end to restore the source-end synchronization relationship and resource mapping relationship.

[0033] S2 includes obtaining thread state snapshots and data checksum values ​​from an initialized synchronization marker dataset, sending the thread state snapshots and data checksum values ​​through the target end transmission process, and obtaining a set of snapshots after transmission; for the set of snapshots after transmission, decoding the synchronization markers using inheritance marker parsing rules, which perform bit-by-bit matching by comparing the marker bit sequence to generate a control module state cache at the target end, and obtaining decoded cache data; based on the decoded cache data, dynamically adjusting the checksum by fusing a preset priority sorting sequence, which adjusts the checksum by adding or subtracting to correct the difference between the checksum value and the priority value, and determining the adjusted priority sequence; verifying cache consistency by combining the adjusted priority sequence with the initialized marker fusion, which performs consistency verification by merging the marker dataset with the corresponding items in the sequence, and obtaining a preliminary synchronization marker inheritance result.

[0034] In this embodiment, the initialized synchronization tag dataset is generated and stored in the source storage space upon completion of step S1. This dataset consists of multiple tag records, each corresponding to a thread within the migration range. Each tag record includes at least the thread identifier value, a thread state snapshot collected from the source, a data checksum value calculated for the thread, and an initial priority value assigned to the thread by the source. In this embodiment, it also includes the network mapping address and peer communication address information corresponding to the thread. The thread state snapshot is a structured data set collected from the source based on the thread's running state. This set includes fields such as synchronization tag, transmission location, and resource usage during the thread's most recent transmission. The data checksum value is generated by the source during the initialization of the synchronization tag dataset generation phase according to a fixed... The integer obtained by the algorithm is calculated as follows: For a certain thread, the system reads each numerical field in the thread state snapshot, the initial priority value of the thread, and the parts of the network mapping address field and peer communication address field of the thread in integer form in a pre-agreed fixed order. Each integer read is added to the current accumulated result. When processing the first integer, the accumulated result is initialized to the integer itself. This process is continued until all relevant integers are included in the accumulation, resulting in an accumulated sum. Then, the system takes a fixed integer as the modulus. In this embodiment, the modulus is 256. The system performs an integer division operation on the accumulated sum and takes the remainder. The remainder is an integer in the range of 0 to 255. This integer is used as the data check code value of the thread and written into the corresponding tag record.

[0035] When entering step S2, the source system first reads each marked record from the initialized synchronization mark dataset in record order. For the current marked record, the system extracts the thread state snapshot data and the pre-calculated data checksum value, and simultaneously reads the thread identifier value of that thread. A transmission record is then constructed in the source memory for the data to be sent. This transmission record contains a record header and a record body. The record header contains fixed fields such as the thread identifier value, the length of the thread state snapshot data, and the length of the data checksum value. The record body contains the original content of the thread state snapshot and the data checksum value in sequence. After construction, the transmission record is placed in the sending buffer. The target transmission process is completed by the cooperation of the source sender and the target receiver. The source sender sends the transmission records in the sending buffer one by one through the predetermined communication link according to the order of the marked records in the initialized synchronization mark dataset. The target receiver receives the transmission records one by one in the receiving order. For each transmission record, the target receiver calculates the length of the thread state snapshot and the length of the data checksum value in the record header. The thread state snapshot data and data checksum value are parsed from the record body. Simultaneously, the data checksum value calculation process is re-executed on the target end. This involves cumulatively adding the received thread state snapshot data and integers such as the initial priority field, and then taking the remainder after dividing by 256 to obtain a locally calculated checksum result. This locally calculated checksum result is compared with the data checksum value carried in the record. If the two values ​​are identical, the target end determines that the record was transmitted correctly and stores the thread state snapshot and data checksum value from that record in their original order into the target end's post-transmission snapshot set. The thread identifier is also appended to the corresponding entry. If the two values ​​are different, the target end determines that the record was transmitted incorrectly. In this embodiment, records with transmission errors are not added to the post-transmission snapshot set, thus ensuring that the post-transmission snapshot set only contains thread state snapshots that passed the checksum. After all records have been transmitted and received, the post-transmission snapshot set is formed. This set is an ordered data set, where each data item contains a thread identifier, a thread state snapshot, and the original data checksum value for that thread.

[0036] After obtaining the snapshot set after transmission, the system executes the inheritance mark resolution rule for each data item in the set to decode the synchronization mark. The thread state snapshot contains a synchronization mark field, which is stored in the form of a mark bit sequence. The length of the synchronization mark field for the same thread is fixed. In this embodiment, the mark bit sequence consists of 16 mark bits, each mark bit being either 0 or 1. Each mark bit at a specific position represents a specific synchronization meaning. For example, the first mark bit represents whether initialization synchronization has been completed, the second mark bit represents whether there is an incomplete recovery action, the third mark bit represents whether the current thread is in a state of waiting for other threads, and the remaining mark bits correspond to other explicitly agreed synchronization states in sequence. The inheritance mark resolution rule is a set of rules pre-defined during the system design phase. In this rule set, the synchronization meaning corresponding to a mark bit value of 0 and a mark bit value of 1 are given for each specific position in the mark bit sequence. During decoding, the target device processes each data item in the transmitted snapshot set sequentially, reading the sequence of flag bits in that data item. Starting from the first flag bit, it processes each flag bit sequentially up to the sixteenth. For the currently processed flag bit, the system reads its value. If the value is 0, it retrieves the synchronization meaning corresponding to the value 0 from the inherited flag parsing rules and writes this meaning into the synchronization state record of the current thread on the target device. If the value is 1, it retrieves the synchronization meaning corresponding to the value 1 from the rules and writes it into the synchronization state record. When a flag bit at a certain position contains an illegal value that is neither 0 nor 1, the system in this implementation sets the synchronization meaning corresponding to that position to a safe state, such as an incomplete state, to prevent misjudgment as a completed state. Simultaneously, it internally marks that this position as abnormal. After completing the bit-by-bit matching and meaning writing of the 16 flag bits, the system obtains the complete synchronization flag decoding result for that thread, which includes a clear description of each synchronization state of that thread.

[0037] The target end constructs a control module state cache to store the decoding results. The control module state cache is a logical storage area on the target end, which consists of multiple cache records. Each cache record corresponds to a data item in the snapshot set after transmission. For the current thread, the system creates a new cache record in the control module state cache, writes the thread identifier of the thread to the identifier field of the cache record, writes the other state information of the thread state snapshot of the thread (excluding the marker bit sequence) to the state field, writes the just obtained synchronization marker decoding result to the synchronization field, and writes the data checksum value corresponding to the thread to the check field. After performing the above operations on all data items in the snapshot set after transmission, the control module state cache is filled, and the set of all cache records constitutes the decoded cache data.

[0038] After obtaining the decoded cached data, the system dynamically adjusts the checksum based on the decoded cached data and a preset priority sorting sequence. The preset priority sorting sequence is an ordered integer sequence generated by the source end before migration based on the importance of each thread in the business process and historical transmission data. In this embodiment, the length of the sequence is the same as the number of threads participating in the migration. Each thread corresponds to a priority value, which is an integer between 1 and 100. The larger the value, the more important the thread. When generating this sequence at the source end, the system counts the number of critical tasks processed by each thread per unit time and the role of the thread in the entire communication process. Threads with a large number of critical tasks and playing a control role are assigned larger priority values, while non-critical task threads are assigned smaller priority values. Then, the threads are arranged in descending order of priority values ​​to form the final preset priority sorting sequence, and the thread identifier is associated with and saved one by one with the corresponding priority value. When the target end performs dynamic checksum adjustment, it first determines the original priority value of each thread according to a preset priority sorting sequence. For each cache record in the decoded cache data, the target end reads the thread identifier in the record, finds the original priority value corresponding to the thread identifier in the preset priority sorting sequence, and then reads the data checksum value of the thread from the checksum field in the cache record. The data checksum value is compared with the original priority value. If the data checksum value is greater than the original priority value, the system calculates the difference by subtracting the original priority value from the data checksum value to obtain a positive integer. This positive integer is used as a correction amount to increase the priority. Then, the original priority value is added to the correction amount to obtain the new priority value for the thread. If the data checksum value is less than the original priority value, the system also calculates the difference between the two. The calculation method is to subtract the data checksum value from the original priority value to obtain a positive integer, and use this positive integer as the correction amount to reduce the priority. Then, subtract the correction amount from the original priority value to obtain the new priority value of the thread. If the data checksum value is equal to the original priority value, the difference is 0, and the system keeps the priority value of the thread unchanged and directly uses the original priority value as the new priority value of the thread. By performing the above comparison and increment / decrement operations on each cached record, the target end obtains an adjusted priority value for each thread. The new priority values ​​of all threads are arranged in order according to the original thread order or by thread identifier to form an adjusted priority sequence.

[0039] After completing the adjusted priority sequence calculation, the system verifies cache consistency using the adjusted priority sequence combined with initialization mark fusion. Initialization mark fusion uses the marked records in the initialized synchronized mark dataset as a benchmark. The system pre-sets a consistency threshold for priority consistency judgment, which is equal to the upper limit of the allowable deviation range. The consistency threshold is determined during system deployment according to the following process: First, the preset priority sorting sequence is scanned to find the maximum and minimum values ​​of all priority values ​​in the sequence. Then, the maximum value is subtracted from the minimum value to obtain the priority range span. Next, this range span is divided by the integer 10 to obtain a quotient. This quotient is rounded down to obtain an integer, which is used as the consistency threshold in this embodiment. For example, when the maximum value is less than 10, the minimum value is used as the consistency threshold. When the maximum value is 100 and the minimum value is 1, the range is 99. Dividing 99 by 10 gives a quotient of 9.9, which is rounded down to 9. Therefore, the consistency threshold is 9. In actual calculations, the system only uses the integer 9 as the threshold for comparison. During consistency verification, the system uses the thread identifier as an index to pair each tag record in the initialized synchronization tag dataset with the corresponding cache record in the control module's state cache. At the same time, it also associates the corresponding priority values ​​in the adjusted priority sequence. For the current thread, the system first compares the synchronization tag field stored in the initialized synchronization tag dataset with the decoded value in the control module's state cache. The synchronization flag field is used to determine if the synchronization flag values ​​in both fields are identical and there are no illegal flag bits. The system then compares the original priority value stored in the initialized synchronization flag dataset with the corresponding new priority value in the adjusted priority sequence. The larger of the two values ​​is subtracted from the smaller value to obtain a difference. If this difference is less than or equal to the aforementioned consistency threshold, the system determines that the thread's priority change is within the allowable deviation range and considers the original and new priorities to be consistent in terms of synchronization inheritance. If the difference is greater than the consistency threshold, the system determines that the thread's priority change during migration is too large and considers the priority inheritance result inconsistent. Only when the thread's synchronization flag field is identical and the priority difference is not greater than the consistency threshold is the system marked as having successfully inherited the synchronization flag, and the thread's synchronization flag and new priority value are written into the preliminary synchronization flag inheritance result. If any comparison fails, the system marks the thread as having failed inheritance and does not write it into the preliminary synchronization flag inheritance result. After completing the above consistency checks for all threads, the set of all threads marked as having successfully inherited constitutes the preliminary synchronization flag inheritance result.

[0040] Throughout the above process, the initialized synchronization marker dataset is generated at the source end in step S1 based on thread running states and resource mapping relationships, with each record strictly corresponding to one thread; the thread state snapshot is recorded in real time by the source end when collecting thread running states, including fields such as synchronization markers, transmission positions, and resource usage; the data checksum value is calculated using an algorithm of summation and modulo 256; the marker bit sequence is the specific representation of the synchronization marker field in the thread state snapshot, with each marker bit being a value of 0 or 1; the inherited marker parsing rule is a set of rules that correspond one-to-one between the values ​​at each position in the marker bit sequence and the specific synchronization meaning; the control module state cache is a storage area allocated in the target end's memory to store the decoded thread state; the decoded cache data is the set of all cached records in the control module state cache; the preset priority sorting sequence is determined by the source end root before migration. The process involves generating an ordered integer sequence based on thread importance and historical transmission data; dynamic checksum adjustment is a specific calculation process that increases or decreases priority by using the difference between the data checksum value and the original priority value as a correction amount; the adjusted priority sequence is an ordered set of new priority values ​​obtained after all threads have undergone dynamic adjustment; the consistency threshold is an integer calculated based on the maximum and minimum values ​​in the preset priority sorting sequence, used to limit the maximum allowable difference between the initial priority and the adjusted priority; initialization mark fusion is a process that uses thread identifiers as indexes to merge the mark records in the initial synchronization mark dataset, the decoded cached data, and the adjusted priority sequence one by one, and performs consistency checks; the preliminary synchronization mark inheritance result is a set of thread synchronization marks that have passed the synchronization mark consistency check and priority difference judgment.

[0041] S3 includes obtaining the update frequency value and state transition trigger condition from the initial synchronization mark inheritance result; performing a matching operation by comparing the update frequency value with a preset threshold to obtain a frequency matching set; for the frequency matching set, adjusting the thread lock resource state in the target control module state cache according to the state transition trigger condition; generating adjusted lock state data by comparing the lock resource state with the allocation threshold for verification; obtaining the adjusted lock state data; handling mark conflicts by combining inheritance conflict resolution logic; if the conflict value exceeds the preset threshold, performing priority sequence correction; determining the conflict handling sequence by comparing the conflict value with the sequence item; decoding the synchronization mark by fusing the conflict handling sequence with the parsing rules; the parsing rules generate the updated control module state cache by matching the mark bit sequence bit by bit to obtain the cache update set; performing consistency verification on the cache update set; comparing the fused data check code value with the initialization mark to determine the updated state consistency verification result.

[0042] In this embodiment, firstly, the initial synchronization mark inheritance result is an ordered set of records formed on the target end after step S2. Each record in this set corresponds one-to-one with a thread. Each record contains at least the thread identifier value of the thread, the synchronization mark content that the thread has inherited and verified on the target end, the priority value obtained by the thread in the previous stage, and the number of times the synchronization mark of the thread has changed during the observation time and the corresponding time information. In this embodiment, the synchronization mark change count field is denoted as the update count field, and the time information field is denoted as the observation time length field. The observation time length is in milliseconds and represents the time difference from the first recording of the thread's synchronization mark to the most recent recording of the thread's synchronization mark. When the system starts in step S3, it first calculates the update frequency value of the thread for each record in the initial synchronization mark inheritance result. The calculation process is as follows: The system sequentially reads the update count field and observation time length field from each record. When the observation time length of a record is greater than 0, the system uses the update count in that record as the dividend and the observation time length as the divisor to perform a division operation. The quotient is taken as the update frequency value of that thread. This update frequency value represents the average number of times the thread's synchronous marker changes within 1 millisecond. When the observation time length is equal to 0, to avoid the case of division by 0, the system directly sets the update frequency value of that thread to 0 and marks it in the thread record that the thread has not made a valid update in the current observation period. After completing the calculation of the update frequency values ​​of all threads, the system obtains a set of update frequency values. After calculating all update frequency values, the system needs to determine the preset threshold for matching. In this embodiment, the preset threshold is calculated from the update frequency values ​​of all threads.

[0043] Specifically, the system first counts the total number of threads recorded in the preliminary synchronization mark inheritance results. It then sums the update frequency values ​​of all threads to obtain a total update frequency. This total update frequency is then divided by the total number of threads to obtain an average update frequency value. This average update frequency value is directly used as a preset threshold for the update frequency. This threshold is a non-negative real number representing the overall average synchronization mark change frequency of all threads. After obtaining the preset threshold, the system performs a matching operation on each thread, comparing its update frequency value with the preset threshold. When a thread's update frequency value is greater than or equal to the preset threshold, it indicates that the thread's synchronization mark has changed. The number of updates is relatively high overall. The system adds the thread identifier of this thread to the frequency matching set. When the update frequency of a thread is less than a preset threshold, the system does not add that thread to the frequency matching set. The final frequency matching set is a set containing several thread identifiers, where the threads have update frequencies no lower than the average level. Subsequently, based on the frequency matching set and the state transition triggering conditions, the system adjusts the thread lock resource state in the target control module's state cache. The target control module's state cache is a cache area established in the aforementioned steps. Each cache record in this cache area corresponds to a thread, and the cache record contains the thread identifier and synchronization... The code includes fields such as the tag decoding result and thread lock resource status. The thread lock resource status field uses an integer encoding to represent the type of lock resource held by the current thread on the target end. In this embodiment, a value of 0 indicates that the thread currently does not hold any lock resource, a value of 1 indicates that the thread currently holds a shared lock, and a value of 2 indicates that the thread currently holds an exclusive lock. The initial synchronization tag inheritance result also includes the state transition trigger condition for each thread. This condition is an integer encoding obtained from the combination of lock-related bits in the synchronization tag during the previous stage of parsing the synchronization tag. In this embodiment, the process of determining the state transition trigger condition is as follows: the system reserves two bits in the tag bit sequence of the synchronization tag for... The bits representing the expected lock state are: the first bit indicates whether the lock needs to be held, and the second bit indicates the expected lock type. When the first bit is 1 and the second bit is 0, it means that the thread expects to acquire an exclusive lock, and the system sets the state transition trigger condition to 1. When the first bit is 1 and the second bit is 1, it means that the thread expects to acquire a shared lock, and the system sets the state transition trigger condition to 2. When the first bit is 0, regardless of whether the second bit is 0 or 1, it means that the thread does not need to hold the lock, and the system sets the state transition trigger condition to 3. In this way, each thread has a clear integer code as the state transition trigger condition.When adjusting the thread lock resource state, the system retrieves thread identifiers one by one from the frequency matching set, finds the corresponding cache record in the target control module's state cache, and reads the state transition trigger condition code for that thread. When the code is 1, the system directly sets the thread lock resource state field of that thread to 2; when the code is 2, the system directly sets the thread lock resource state field of that thread to 1; and when the code is 3, the system directly sets the thread lock resource state field of that thread to 0. For threads outside the frequency matching set, the system does not change their thread lock resource state field, keeping its value unchanged at the end of step S2. After this processing step, the system obtains a preliminary lock state adjustment result based on the update frequency and state transition trigger condition. To prevent excessive lock resource occupation due to a large number of threads being set to the holding state, the system needs to perform a fusion verification by comparing the lock resource state with the allocation threshold to generate adjusted lock state data. Here, the allocation threshold is an integer parameter used to limit the number of threads simultaneously in the holding state. In this embodiment, the allocation threshold is indeed... The process is as follows: The system counts the total number of threads in the target control module's state cache, divides the total number of threads by 2. If the total number of threads is even, the division result is an integer, which the system directly uses as the allocation threshold. If the total number of threads is odd, the division result contains a decimal part, which the system discards, keeping only the integer part, and using this integer as the allocation threshold. When the total number of threads is 1, the system sets the allocation threshold to 1 to ensure that at least one thread can hold the lock resource. After obtaining the allocation threshold, the system counts the number of threads whose thread lock resource status field is 1 or 2 in the initial lock state adjustment results, compares this number with the allocation threshold. If this number is less than or equal to the allocation threshold, it means that the number of threads currently holding the lock has not exceeded the limit, and the system directly writes the existing value of the thread lock resource status field of each thread into a new lock state data set. The new set is the adjusted lock state data. If this number is greater than the allocation threshold, it means that the number of threads currently holding the lock has exceeded the limit, and the system needs to further filter according to priority.

[0044] The specific process is as follows: The system extracts all thread identifiers with thread lock resource status fields set to 1 or 2 from the target control module's state cache. It then reads the priority values ​​of these threads from the priority sequence obtained in the previous stage and sorts them according to their priority values ​​from largest to smallest. After sorting, the system sequentially extracts the top few threads from the sorted results; this number equals the allocation threshold. For these threads at the top of the sorted results, the system retains their existing thread lock resource status field values. For the remaining threads in the sorted results, the system uniformly rewrites their thread lock resource status fields to 0, indicating that no more lock resources will be allocated. After the rewriting is complete, the final thread lock resource status fields of all threads are written to the lock state count. The system uses a set, where each record contains a thread identifier and a final thread lock resource state value. This set serves as the adjusted lock state data. Subsequently, the system extracts the thread lock resource state value for each thread from the adjusted lock state data and handles the marking conflict using inheritance conflict resolution logic. In this implementation, the role of inheritance conflict resolution logic is to quantify the degree of difference between the expected lock state in the synchronization mark and the adjusted actual lock state and to adjust the priority based on the difference. A marking conflict refers to an inconsistency between the expected lock state revealed by the synchronization mark in the initial synchronization mark inheritance result of a thread and the thread lock resource state in the adjusted lock state data. In this implementation, a conflict value is calculated for each thread to represent the degree of this inconsistency.

[0045] The specific calculation process is as follows: The system reads the flag bit sequence corresponding to the thread's synchronization flag from the initial synchronization flag inheritance result. In the two reserved bits representing the expected lock state, the expected lock state code is determined according to the aforementioned rules. When the bit indicating whether the lock is held is 0, the expected lock state code is 0; when the bit indicating whether the lock is held is 1 and the bit indicating the lock type is 0, the expected lock state code is 2; when the bit indicating whether the lock is held is 1 and the bit indicating the lock type is 1, the expected lock state code is 1. Then, the system reads the final thread lock resource state field value from the adjusted lock state data and compares this field value with the expected lock state code. If they are equal, the system sets the thread's conflict value to 0, indicating that the thread does not have a lock state conflict. If they are not equal, the system takes the larger of the two values ​​and subtracts the smaller value from the larger value to obtain a positive integer. This positive integer is used as the thread's conflict value. The larger the conflict value, the greater the deviation between the expected lock state and the actual lock state. During the deployment phase, a preset threshold is set for the conflict value. In this embodiment, the preset threshold is fixed at 1. That is, a conflict value of 1 or less is considered to be within the tolerable range, while a conflict value greater than 1 is considered to be a serious conflict, requiring further priority adjustment. After the system completes the calculation of all thread conflict values, it begins to perform priority sequence correction according to the inherited conflict resolution logic. For each thread, when its conflict value is less than or equal to the preset threshold, the system does not modify the thread's priority value in the priority sequence. When its conflict value is greater than the preset threshold, the system reads the thread's priority value from the current priority sequence, subtracts the thread's conflict value from the priority value to obtain a new priority value. When the new priority value is less than 1, the system forces the new priority value to be set to 1 to ensure that the priority value is always greater than or equal to 1. Then, the new priority value replaces the original priority value of the thread in the priority sequence, completing the priority sequence correction for the thread. Through this processing step, the system obtains a priority sequence that has been corrected according to the lock state conflict situation.

[0046] Next, the system determines the conflict resolution sequence by comparing conflict values ​​with sequence entries. Here, sequence entries refer to the priority values ​​corresponding to each thread in the corrected priority sequence. The system creates a thread list to construct the conflict resolution sequence, where each entry contains a thread identifier, the thread's conflict value, and the corrected priority value. The system first sorts the list from largest to smallest conflict value. During sorting, if two threads have the same conflict value, the system then sorts these two threads according to their corrected priority values, placing the thread with the larger corrected priority value first. Sorting can be achieved by repeatedly traversing the list to find the currently unoutputted largest conflict value entry and writing it sequentially into a new list. The resulting ordered list of threads is the conflict handling sequence. This sequence clarifies the order in which synchronization tags are processed for each thread, ensuring that threads with larger conflicts are processed first. The system then decodes the synchronization tags using the conflict handling sequence fusion parsing rules. In this implementation, the parsing rules follow the aforementioned inherited tag parsing rules, still employing a bit-by-bit matching method to convert the tags into specific synchronization state meanings. Specifically, the system processes threads sequentially according to the conflict handling sequence. For each thread, it first reads the currently stored tag bit sequence from the target control module's state cache and rewrites the two bits representing the desired lock state based on the adjusted lock state data. To ensure a completely consistent combination with the thread lock resource status field, when the thread lock resource status field is 0, the system writes 0 to the bit indicating whether the lock is held and 0 to the bit indicating the lock type. When the thread lock resource status field is 1, the system writes 1 to the bit indicating whether the lock is held and 1 to the bit indicating the lock type. When the thread lock resource status field is 2, the system writes 1 to the bit indicating whether the lock is held and 0 to the bit indicating the lock type. This rewriting operation ensures that the lock-related information in the marker bit sequence is consistent with the latest thread lock resource status. After the rewriting is complete, the system reads the value of each bit sequentially starting from the first bit of the thread marker bit sequence. For the current bit, the system parses the rules... The system searches for the meaning definition corresponding to the position of the bit. When the bit value is 0, it takes the predefined meaning of 0 at that position; when the bit value is 1, it takes the predefined meaning of 1 at that position. The obtained synchronization state meaning is written into the synchronization state field of the corresponding record in the control module's state cache. This process continues until all bits are processed, completing the synchronization mark update decoding for one thread. Then, the system continues to process the next thread according to the conflict handling sequence. After all threads have been processed, the system obtains a set of cache records that have been updated based on the latest lock state and priority correction results. These records are combined into a cache update set. Each cache record in this set contains the latest synchronization mark decoding result and the matching thread lock resource state information.Finally, the system performs a consistency check on the cached update set, compares the data checksum values ​​with the initialization flags, and determines the consistency check result of the updated state.

[0047] The consistency verification process is as follows: The system recalculates the data checksum value for each cache record in the cache update set. The calculation method is the same as the method for generating the data checksum value in steps S1 and S2. That is, the system reads each key field stored in integer form in the cache record in a pre-agreed order, adds these integers one by one to obtain a sum, and then selects a fixed modulus. In this embodiment, the modulus is 256. The system performs an integer division operation between the sum and 256 and takes the remainder. The remainder is used as the data checksum value updated by the thread. Subsequently, the system searches for the initial flag record of the thread in the initialization flag according to the thread identifier, reads the original data checksum value and the original synchronization flag content stored therein, and compares the recalculated data checksum value with the original... The system compares the data checksum values. When the two values ​​are exactly the same, the system considers that the overall data consistency of the thread has not been compromised after the cache update. Based on this, the system then compares the key bits of the latest synchronization mark of the thread in the cache update set with the corresponding bits in the initialization mark. When the values ​​of all key bits are consistent with the initialization mark, the system marks the thread as consistent and writes the result into the updated state consistency check result set. When the recalculated data checksum value is different from the original data checksum value or there is an inconsistency in the key bits, the system marks the thread as inconsistent and writes it into the updated state consistency check result set. After all threads have been checked, the updated state consistency check result set contains the consistency judgment result of each thread. In the above, the update frequency value is obtained by dividing the number of updates and the observation time length. The preset update frequency threshold is determined by the average of the update frequency values. The state transition trigger condition is determined by the combination of lock-related bits in the marker bit sequence. The thread lock resource state is directly set by the frequency matching set and the state transition trigger condition and limited by the allocation threshold. The allocation threshold is determined by dividing the total number of threads by 2 and taking the integer part. The conflict value is determined by the difference between the expected lock state code and the actual thread lock resource state code. The preset threshold for the conflict value is fixed at 1. The priority sequence correction is completed by subtracting the original priority value from the conflict value. The conflict handling sequence is generated by jointly sorting the conflict value and the corrected priority. The parsing rule establishes a one-to-one synchronization meaning for each bit's 0 and 1 with the marker bit position as the index. The data check code value is obtained by taking the remainder of the sum of the key integer fields modulo 256.

[0048] S4 includes obtaining module status log records and module resource usage tables from the target module based on the state consistency verification result. The state consistency verification is performed by comparing the differences in module parameters between the source and target ends. If the difference is less than a preset threshold, the verification is considered successful. The resulting module status log records are used to record the module's operational history, and the module resource usage table is used to display resource usage. For the module status log records and module resource usage table, the synchronization signal priority and transmission interruption recovery point of the source end are matched. The synchronization signal priority is sorted according to signal urgency, and the transmission interruption recovery point is restored by recording the interruption location, resulting in a matched priority sequence. Based on the matched priority sequence, the process is then... The new mapping targets communication address resources, where remapping employs an address reallocation method to convert old addresses to new addresses to optimize connections. An anomaly recovery service is introduced to repair potential faults by analyzing module status logs, determining the mapped address configuration. From the mapped address configuration, an adjusted communication topology adaptation scheme is constructed. This scheme integrates address resources and priorities, introducing a dynamic priority adjustment service to modify priorities based on real-time load. If the load exceeds a threshold, low-priority signals are reduced, resulting in a preliminary adaptation scheme. This preliminary adaptation scheme is then finalized and its stability is tested through simulated transmission, yielding the adjusted communication topology adaptation scheme.

[0049] In this embodiment, firstly, the state consistency verification result is a result set formed on the target end after completing the aforementioned steps. Each record in this result set corresponds one-to-one with a module on the target end. Each record contains at least a module identifier, a source module parameter set, a target module parameter set, and a state consistency flag for that module. The module identifier is a unique integer number assigned to each module during system initialization to distinguish different modules. The source module parameter set and the target module parameter set are snapshots of the module's operating parameters on the source and target ends, respectively. Specifically, they include five defined numerical parameters: processor utilization, graphics processing unit utilization, memory usage, network bandwidth usage, and error count. Processor utilization and graphics processing unit utilization are recorded as percentage values, memory usage is recorded in bytes or integer multiples of bytes, network bandwidth usage is recorded as bytes transmitted per second, and the error count is the number of error events collected within a fixed observation period. The specific calculation process for state consistency verification is as follows: the system first collects the above five parameters for each module at fixed time intervals during the source end operation phase, and summarizes the collection results at each moment into the source module parameter set.

[0050] After migration, the target system collects the same five parameters for each module at equal time intervals, summarizing them into a target module parameter set. Then, for each parameter item of a given module, the system takes the source and target parameter values ​​separately, calculating the difference for each parameter item. The difference is calculated by subtracting the target parameter value from the source parameter value and taking the absolute value. For example, if a module's processor utilization is 70% on the source and 65% on the target, the difference for that parameter item is 5. This difference calculation is performed for each of the five parameters, and the five difference values ​​are summed one by one to obtain the total difference. The total difference is then divided by 5 to obtain the average parameter difference for that module. The larger this average parameter difference value, the better the module's performance in the source and target scenarios. The greater the difference in the operating states between the target and end terminals, the greater the difference in their operating states. The preset threshold used in the state consistency check is calculated from the average parameter difference value of all modules. Specifically, the system adds up the average parameter difference values ​​of all modules one by one to obtain the average sum of differences. Then, it divides the average sum of differences by the total number of modules to obtain a global average difference value. This global average difference value is used as the preset threshold for state consistency check. This preset threshold is a non-negative real number, representing the upper limit of the average parameter difference allowed by the system. During the check, for each module, the system compares the average parameter difference value of that module with the preset threshold. When the average parameter difference value of a module is less than or equal to the preset threshold, the state of that module is changed. Consistency is marked as passed. When the average parameter difference of a module exceeds a preset threshold, the consistency of that module is marked as failed. The consistency verification result set only retains the module identifiers marked as passed and their corresponding parameter sets, which are used in the next step to obtain module status log records and module resource usage tables from the target module. The module status log record is a data set that records the running process of each module that passes the verification in chronological order. In this embodiment, each log record includes at least a log timestamp, event type, related module identifier, related thread identifier, related communication address, current key parameter summary, and error code field. The log timestamp is in milliseconds. The event type is an integer code representing start, stop, interrupt, reconnection, error, etc. The related communication address is the communication address value used by the module when the event occurs. The current key parameter summary is a combination of parameters such as processor utilization, memory usage, and network bandwidth usage at the same time. The error code is an integer code representing the error category. The module resource usage table is a statistical result of the resource usage of each module at a certain time or within a certain time period. Each row records the resource usage of a module or a communication address. The table includes fields such as module identifier, communication address, processor usage percentage, graphics processing unit usage percentage, memory usage in bytes, and network bandwidth usage in bytes per second.At the beginning of step S4, based on the module identifier in the state consistency verification result, the system reads the log file corresponding to the module identifier from the target storage system for each module that passes the verification. The log file content is parsed into several log records according to a fixed format, and these records are saved as a module state log record set. Simultaneously, the system reads the resource statistics file generated for that module, converts the resource usage statistics into a standardized table format, and saves it as a module resource occupancy table. This completes the specific process of obtaining the module state log records and module resource occupancy table based on the state consistency verification result. Next, the system matches the module state log records and module resource occupancy table with the synchronization signal from the source end. Priority and transmission interruption recovery point: The synchronization signal priority is a priority value calculated for each synchronization signal or each thread in the preceding steps. In this embodiment, the priority value is an integer greater than or equal to 1. The larger the value, the higher the urgency of the signal. The urgency of the signal is directly quantified using this priority value, without introducing a new measurement method. The transmission interruption recovery point is the interruption location description information determined by the source end for each thread when analyzing the thread state snapshot. In this embodiment, the transmission interruption recovery point includes at least two integer parameters: the packet sequence number at the time of the interruption and the number of bytes successfully transmitted. The packet sequence number is used to determine which packet in the data stream the interruption occurred in. The number of bytes successfully transmitted is used to determine the length of valid data that has been transmitted within the packet. When recovery occurs at the target end, the system locates the corresponding data packet position and byte offset position based on the transmission interruption recovery point, and continues data transmission or reception from that position to achieve interruption position recovery. The specific implementation of the matching process is as follows: The system first constructs a matching table, which is indexed by thread identifier or signal identifier. Each index entry reserves a synchronization signal priority field, a transmission interruption recovery point field, and a home module identifier field. Then, the system traverses the module status log record set, reads the thread identifier and event type from each log record, and selects the record with the specified event type. When the event type encoding indicates that the event is a transmission interruption, the system selects the corresponding log record. When an interruption recovery event caused by reconnection or error occurs, the system extracts the thread identifier, log timestamp, and related communication address from the log record. Then, it finds the synchronization signal priority and transmission interruption recovery point corresponding to the thread from the existing initialization synchronization mark dataset. The synchronization signal priority and transmission interruption recovery point are written into the corresponding field of the thread identifier index in the matching table. At the same time, the module identifier of the current log record is written into the belonging module identifier field. If a log record only records the communication address without explicitly recording the thread identifier, the system first finds the thread identifier to which the communication address belongs based on the correspondence between communication address and thread identifier in the module resource usage table, and then updates the corresponding index entry in the matching table.When the same thread experiences multiple interruption or reconnection events across multiple log records, the system compares the timestamps of these log records and retains only the record with the latest timestamp for matching, ensuring that the transmission interruption recovery point information corresponds to the most recent interruption state. After scanning all log records, each valid index entry in the matching table is filled with synchronization signal priority, transmission interruption recovery point, and owner module information. To obtain the priority sequence after matching, the system sorts all valid index entries in the matching table from highest to lowest synchronization signal priority. When multiple index entries with the same synchronization signal priority are encountered, they are further sorted from most recent to oldest log timestamp, i.e., prioritizing the most recently occurring interruption or reconnection event. The signals are sorted, and the result is the matched priority sequence. Each item in this sequence contains a thread identifier, synchronization signal priority, transmission interruption recovery point, and the identifier of the owning module. Then, the system begins to remap the target end communication address resources according to the matched priority sequence. The target end communication address resources are a set of address values ​​that the target end can use for data transmission, including network mapping addresses, peer communication addresses, etc. After the migration is complete, the old addresses need to be converted to new addresses using an address reallocation method to optimize the connection. The specific process of the address reallocation method is as follows: The system first constructs an old address table based on the module resource occupancy table. Each row in the table records the module affiliation of a communication address, the current address, the priority of the synchronization signal, the transmission interruption recovery point, and the identifier of the owning module. The system first obtains the current load value and physical node information. The current load value can be represented by the ratio of the current network bandwidth usage of the address to the theoretical maximum bandwidth. The physical node information indicates the server or network node where the address is located. Then, the system constructs an available address pool, collecting candidate addresses from the set of communication addresses that are not occupied or have low load at the target end. Each candidate address records its physical node and current load value. During remapping, the system processes each index entry from beginning to end according to the priority sequence after matching. For the currently processed index entry, the system looks up the old address currently used by the module in the old address table based on the module identifier, and filters the available address pool for addresses that are physically related to the module. The communication address that is identical to the node or is closest to the physical node in the network topology and has the lowest current load value is selected as the new address. The correspondence between the old address and the new address is recorded in an address mapping table, and the new address is marked as occupied from the available address pool to avoid duplicate allocation. When there is no address in the available address pool that completely matches the physical node of the module, the system selects the communication address of the node that is closest to the physical node in the network topology and uses it as the new address. This process continues until all items in the priority sequence after matching have completed the allocation of new addresses. Each row in the address mapping table records the old address, the new address, the corresponding module identifier, and the corresponding thread identifier. This table is the initial address configuration after mapping.Based on this, to repair potential faults, the system introduces an abnormal state repair service. This service identifies old addresses with potential faults by analyzing error codes or abnormal events in the module status log records and corrects the mapping relationships corresponding to these addresses. Specifically, the system rescans the module status log record set. For each log record containing an error code field, it reads the relevant communication address and error code. Based on the error code type, the error events are divided into critical errors and general errors. Critical errors include connection timeouts and multiple failed retries, while general errors include brief successful retries. The system counts the number of critical and general errors for each communication address throughout the entire observation period. Critical error counts are weighted at 2 and included in the total error count, while general error counts are weighted at 1, resulting in the total error count for each communication address. Then, the system determines an error count threshold, which is calculated from the total error count distribution of all communication addresses. Specifically, this threshold is calculated by statistically analyzing the total error count distribution of all communication addresses. The system calculates the total error count for each address, finds the maximum and minimum total error counts, subtracts the minimum total error count from the maximum to obtain the error span, divides the error span by 2 and rounds down to obtain an integer, which is used as the error count threshold. When the total error count of a communication address is greater than or equal to the error count threshold, the communication address is considered to have a high potential fault risk. For old addresses identified as high-risk, the system searches for the corresponding row in the address mapping table, marks the row as an abnormal mapping entry, and selects a new communication address from the available address pool or the alternative address set that has a different physical path than the original and has a lower current load. The corresponding mapping relationship in the address mapping table is updated, and an abnormal repair mark is added to the record to indicate that the mapping relationship has undergone abnormal state repair processing. After this series of address reallocation and abnormal repair operations, the final address mapping table is the repaired and mapped address configuration, which is used to build a communication topology adaptation scheme in the future.After obtaining the mapped address configuration, the system begins to construct an adjusted communication topology adaptation scheme from this configuration. The communication topology adaptation scheme is a comprehensive layout description of the communication relationships between modules on the target side. In this embodiment, the communication topology adaptation scheme consists of several communication connection records. Each communication connection record contains at least four fields: source module identifier, target module identifier, new communication address, and synchronization signal priority on the connection. The construction process is as follows: Based on the matched priority sequence and the mapped address configuration, the system uses each thread or signal as the logical basis for a communication connection. For each thread, it reads its own module identifier and uses it as the source module identifier. Based on business logic or an existing thread communication relationship table, it determines the target module identifier for the thread's communication. Then, it searches the address mapping table for the new mapped communication address corresponding to the thread, writes the source module identifier, target module identifier, new communication address, and the thread's synchronization signal priority into a communication connection record, and adds this record to the communication topology adaptation scheme. This process is repeated until all threads generate corresponding communication connection records. To implement priority modification based on real-time load, the scheme introduces a dynamic priority adjustment service. This service is... A set of rules for automatically adjusting the priority of synchronization signals based on real-time load information is implemented as follows: The system adds a real-time load field to each communication connection record. The initial value of this field is obtained by dividing the network bandwidth usage of the corresponding communication address in the module resource occupancy table by the theoretical maximum bandwidth, representing the current load ratio of the connection. The system also sets a load threshold parameter for dynamic priority adjustment. This load threshold is determined by statistically analyzing the load situation during historical stable operation periods. Specifically, the system selects all load records marked as operating stably in the module resource occupancy table, adds the load ratio values ​​in these records, and divides the sum by the number of records to obtain an average load ratio. This average load ratio is used as the load threshold. When the real-time load ratio of a communication connection is less than or equal to the load threshold, the system keeps the priority of all synchronization signals on that connection unchanged. When the real-time load ratio of a communication connection is greater than the load threshold, the system analyzes the priority of all signals on that connection, calculates the average priority of all signals on that connection, marks signals with priorities lower than this average as low-priority signals, and for each low-priority signal, the system reduces its priority value by a fixed step size.

[0051] The fixed step size is determined as follows: Calculate the difference between the current priority of the low-priority signal and the maximum priority on the connection, divide the difference by 2 and round down to obtain an integer as the reduction step size, subtract this step size from the current priority to obtain the adjusted priority, and force the adjusted priority to be set to 1 when it is less than 1 to prevent the priority from dropping to 0; through this dynamic priority adjustment service, when the load exceeds the threshold, the system will automatically reduce the priority of low-priority signals, thereby releasing more bandwidth resources for high-priority signals, and finally obtain a preliminary adaptation scheme containing static connection information and dynamic priority adjustment rules; after obtaining the preliminary adaptation scheme, in order to determine the availability of the scheme in actual operation, the system also needs to perform a final verification of the scheme, which is completed by simulating transmission to test the stability of the preliminary adaptation scheme.

[0052] The specific process of the simulated transmission test is as follows: Based on each communication connection recorded in the preliminary adaptation plan, the system constructs several simulated transmission tasks for each connection. The number of simulated transmission tasks is determined as follows: the system counts the maximum concurrent connections for that connection or module during historical operation from the module resource occupancy table, using this maximum concurrent connection number as the upper limit for the number of simulated tasks for that connection. Simultaneously, the system counts the data packet size distribution under normal operating conditions in the module status log, using the average of this distribution as the size of each data unit during simulated transmission. During the simulated transmission test, the system starts the corresponding number of simulated tasks according to the new communication address specified for each connection in the preliminary adaptation plan. In these simulated tasks, data units are sent and received at a predetermined rate, and at the sending end, each data unit is processed according to a fixed algorithm. The data unit calculates the data checksum value, and the receiving end recalculates and compares the data checksum value to detect any data corruption. Simultaneously, the system records transmission latency statistics and error event statistics for each connection throughout the entire test period. The transmission latency statistics include the time difference between sending and receiving each data unit, and the error event statistics include the number of data verification failures and connection interruptions. To determine stability thresholds, the system determines two thresholds based on statistical results from historical normal operation records in the module status log before the simulated transmission test: a latency threshold and an error count threshold. The latency threshold is determined by collecting transmission latency data from all data units during the historical normal operation period and taking the maximum value as the latency threshold.

[0053] The error count threshold is determined as follows: During the historical normal operation period, the maximum number of errors allowed per unit time for each connection is counted, and the maximum number of errors per unit time is taken as the error count threshold. After the simulated transmission test, the system checks the test results of each connection. When the transmission delay of all data units of a connection during the test is less than or equal to the delay threshold, the number of errors is less than or equal to the error count threshold, and the data checksum values ​​are all consistent between the sending and receiving ends, the system marks the connection as stable. When any test result of a connection exceeds the threshold limit or there is data check inconsistency, the system marks the connection as unstable. For unstable connections, the system can fine-tune the new communication address or priority allocation based on the initial adaptation scheme, and then repeat the simulated transmission test until all connections pass the stability judgment. When all connections meet the above stability conditions, the system determines the current communication topology adaptation scheme as the adjusted communication topology adaptation scheme. This scheme includes the finally determined mapped address configuration, synchronization signal priority allocation, and dynamic priority adjustment rules.

[0054] S5 includes obtaining a backup address pool from the target end according to the topology adaptation scheme, loading the initial configuration of the communication interface, verifying the accuracy of the address mapping by comparing the difference in code values ​​before and after mapping, and obtaining the verification result; if the verification result is inconsistent, extracting spare resources from the backup address pool, triggering the resource distribution reallocation process, and determining the address configuration after reallocation by adjusting the resource allocation ratio; obtaining the address configuration after reallocation, integrating redundant links in the backup address pool, constructing spare paths for the communication interface by prioritizing the links, and obtaining the path integration configuration; applying the adjusted communication topology adaptation scheme from the path integration configuration, merging redundant links, optimizing the connection through path redundancy verification, and determining the final communication interface operating environment.

[0055] In this embodiment, at the beginning of step S5, the adjusted communication topology adaptation scheme obtained in step S4 has already been implemented. This scheme clearly lists the communication relationships between various modules on the target end, the corresponding communication addresses, and the synchronization signal priorities on each communication connection. Based on this, the system first obtains a backup address pool from the target end according to the topology adaptation scheme. In this embodiment, the backup address pool is a set of spare communication addresses pre-defined during the system deployment phase. Each entry in this set contains at least one communication address value, the identifier of the physical node to which it belongs, a current occupancy flag, and a redundancy level flag. The communication address value is the number of addresses that can be used to establish a network. The address number of the network connection, and the physical node identifier to which it belongs, are unique numbers for each physical server or network node on the target end. The occupancy flag is 0 or 1, where 0 indicates that the address is idle and available, and 1 indicates that the address has been allocated but is in a switchable backup state. The redundancy level flag is an integer greater than or equal to 1, with a larger value indicating a higher priority for the address during failover. This redundancy level is determined during system initialization based on the stability of physical links and historical failure data. Specifically, during the deployment phase, the historical error count and average latency of the link to each communication address are counted, and addresses with fewer error counts and lower average latency are marked with a higher redundancy level. Based on all physical node identifiers appearing in the adjusted communication topology adaptation scheme, the system selects address entries corresponding to these physical node identifiers from the backup address pool to form a backup address sub-pool related to the current topology, which is used for subsequent mapping verification and reallocation.

[0056] Once the backup address pool is obtained, the system begins loading the initialization configuration of each communication interface for the target end. In this embodiment, the initialization configuration of the communication interface refers to a set of fixed parameters that need to be set for each interface before normal operation, including the maximum number of concurrent connections, send buffer size, receive buffer size, maximum number of retries, and timeout. The system reads these parameter values ​​stored in the configuration file for each interface and writes them into the interface control structure, enabling the interface to accept new addresses and initiate connections. During this process, the address mapping relationship will not be changed; it only provides a stable interface environment for subsequent verification and reallocation.

[0057] Subsequently, the system verifies the accuracy of the address mapping by comparing the difference in code values ​​before and after the mapping, based on the data checksum value. In this embodiment, the calculation method of the data checksum value is consistent with the aforementioned steps, that is, the remainder after accumulating several integer fields and taking the remainder after dividing by a fixed modulus. In step S5, for each communication connection, the system already has a set of original mapping information before the address mapping adjustment, including the source module identifier, the target module identifier, the old communication address, and the thread identifier or synchronization signal identifier bound to the connection. The system first calculates the checksum value before mapping for each original mapping record. Specifically, the source module identifier, the target module identifier, the old communication address value, and the thread identifier used to identify the connection are extracted sequentially, and these integers are accumulated one by one in a fixed order. When processing the first integer, the accumulated result is... The integer is set to itself. Starting from the second integer, it is added to the current accumulated result until all integers are accumulated, resulting in an accumulated sum. Then, a fixed modulus is taken. In this embodiment, the modulus is 256. The accumulated sum is divided by the modulus, and the remainder is taken. The remainder is an integer between 0 and 255. This integer is recorded as the pre-mapping checksum value in the checksum record corresponding to the connection. After the address reassignment is completed and the new communication address is determined, the system calculates the post-mapping checksum value for each connection. The calculation process is exactly the same as before mapping, except that the old communication address is replaced with the new communication address after mapping. The other fields remain unchanged. Similarly, by accumulating and taking the remainder of the modulus, an integer in the range of 0 to 255 is obtained as the post-mapping checksum value. The system then compares the difference between the checksum value before and after mapping for each connection. Specifically, it subtracts the smaller checksum value from the larger checksum value to obtain a non-negative integer, which is used as the checksum difference. In this embodiment, the checksum difference threshold is pre-set to 0. That is, when the checksum difference is equal to 0, the checksums before and after mapping are considered to be completely consistent. When the checksum difference is greater than 0, it is considered that there is a difference before and after mapping, and the possibility of errors in the mapping process cannot be ruled out. Thus, the system generates a verification result flag for each connection. The flag value is either pass or fail. When the checksum difference is equal to 0, it is marked as pass. When the checksum difference is greater than 0, it is marked as fail. The set of verification results for all connections constitutes the overall verification result of this step.

[0058] After obtaining the verification results, the system makes a judgment on the verification results. If any connection in the verification results is marked as failing, it is considered as a display inconsistency. At this time, the system extracts spare resources from the backup address pool according to the process specified in the claims and triggers the resource distribution and reallocation process. In this embodiment, spare resources refer to communication address entries in the backup address pool with an occupation flag of 0. These addresses have not yet been used in the current communication topology.

[0059] The specific extraction process is as follows: The system first counts the number of connections that need correction, i.e., the number of connection entries marked as failing in the verification results. Simultaneously, it counts the total number of address entries in the backup address pool with an occupancy flag of 0. When the number of spare resources is greater than or equal to the number of connections that need correction, the system considers the current backup address pool resources sufficient and continues subsequent reallocation calculations. When the number of spare resources is less than the number of connections that need correction, the system allocates spare resources to these higher-priority connections according to the claims. The insufficient resources retain their original mappings and are recorded separately as risky connections in subsequent steps. The resource distribution reallocation process determines the address configuration after reallocation by adjusting the resource allocation ratio. In this embodiment, the resource allocation ratio is the proportion of the number of addresses reserved for each module in the backup address pool to the total number of spare addresses, based on the actual load of the modules.

[0060] The specific calculation process is as follows: The system utilizes the network bandwidth usage and concurrent connection count of each module recorded in the module resource usage table from the previous stage. First, it calculates a load weight value for each module. This load weight value is calculated by multiplying the module's network bandwidth usage by the number of concurrent connections as the base weight value. The larger this base value, the heavier the communication load of the module. The system adds up the base values ​​of all modules to obtain a total weight value. Then, for each module, the base value is divided by the total weight value to obtain a decimal between 0 and 1. This decimal is used as the resource allocation ratio for that module, representing the proportion of all spare resources that should be allocated to that module. After calculating the resource allocation ratio for each module, the system calculates the number of spare addresses corresponding to each module based on the total number of addresses with an occupancy flag of 0 in the backup address pool. The calculation method is to multiply the total number of spare addresses by the module's resource allocation ratio and round the result down to an integer. This integer is used as the number of spare addresses that the module should receive. If the total allocation number is less than the number of spare addresses due to rounding down, the system will not be able to allocate more spare addresses. If the total number of addresses is zero, the remaining few addresses are allocated to the heavily loaded modules in descending order of load weight. Each time, one spare address is added to the module with the highest weight, until all spare addresses are allocated. Then, for connections marked as failing in the verification results, the system replaces their original old addresses with free addresses from the spare address entries allocated in the backup address pool for each module, based on the module to which these connections belong. During replacement, spare addresses from the same physical node or the same network area as the original old address are given priority. If the number of spare addresses for a module is insufficient to replace all its failing connections, connections with higher synchronization signal priority are replaced first. Connections with lower priority and no sufficient spare addresses to allocate are marked as temporarily deferred in the record. After this round of replacement is completed, the system regenerates the redistributed address configuration. Each connection entry in this configuration includes the source module identifier, the target module identifier, the new communication address, and the current synchronization signal priority. These new communication addresses either come from the records that passed the initial mapping verification or from the new addresses redistributed from the backup address pool at this time.

[0061] After obtaining the redistributed address configuration, the system needs to integrate redundant links in the backup address pool. It constructs backup paths for communication interfaces by prioritizing the links, resulting in an integrated path configuration. In this embodiment, redundant links refer to backup communication connections prepared in advance for the communication relationships of various key modules based on the backup address pool and the redistributed address configuration. Each redundant link contains a source module identifier, a target module identifier, and a communication address different from the primary connection. New redundant links come from new address entries in the backup address pool that have not yet been used as primary connections. The system first analyzes the redistributed address configuration and identifies all key communication pairs. A key communication pair refers to a module pair whose synchronization signal priority reaches a certain lower limit in the matched priority sequence. In this embodiment, connections with synchronization signal priorities greater than or equal to a fixed value are defined as key connections. This fixed value can be set in the system configuration, for example, to 50, indicating that signals with a priority value of 50 or higher are considered highly important. The system iterates through all connection entries in the redistributed address configuration and includes connections that meet this condition into the key connection set. For each key connection, the system attempts to select at least one redundant link from the backup address pool.

[0062] The specific approach is as follows: The system searches the backup address pool for communication addresses that are different from the physical nodes of the source module or target module of the critical connection. This aims to construct independent backup paths on the physical path as much as possible. When multiple addresses meet the criteria, the system prioritizes the address with lower load and a higher redundancy level flag. This address is then combined with the source module identifier and target module identifier to generate a redundant link record. The address's occupancy flag is set to 1 in the backup address pool, indicating that the address has been used as a redundant link. After generating one or more redundant links for each critical connection, the system sorts all redundant links according to their priority. In this implementation, a link priority value is calculated for each redundant link. This priority value is determined by three factors: the redundancy level flag, the historical error count of the physical path, and the current load ratio of the path. The specific calculation process is as follows: The system first uses the redundancy level flag directly as the base priority based on its value; the larger the value, the higher the base priority. Then, it searches the module status log for error statistics of the communication addresses involved in the link to obtain the total error of the address during the observation period. To prevent excessive impact from large error counts, the system sets a maximum impact value for error counts. When the error count exceeds this maximum value, it is processed according to the maximum value. The system then obtains the current load ratio of the address from the module resource usage table. The load ratio is the ratio of the current bandwidth usage of the address to the theoretical maximum bandwidth. To standardize the measurement, the system amplifies the load ratio by a certain factor and rounds it down to an integer. Then, the system subtracts the deduction value related to the error count from the base priority, and then subtracts the deduction value related to the load ratio again to obtain the final link priority value. The more error counts, the higher the load ratio, and the larger the deduction value, the lower the link priority value. The system sorts all redundant links from highest to lowest priority. For each source and target module pair, it selects the top few redundant links as backup paths for the communication interface based on the sorting result. Typically, one or two backup paths are reserved for each critical main connection. Based on this selection, the main connection and corresponding backup paths of each module pair are recorded in a path integration configuration. Each record in this configuration includes the source module identifier, target module identifier, main communication address, several backup communication addresses, and the corresponding link priority value. After forming the path integration configuration, the system starts from the path integration configuration, applies the adjusted communication topology adaptation scheme, merges redundant links, optimizes connections through path redundancy verification, and determines the final communication interface operating environment. In this embodiment, path redundancy verification is a process of checking whether the main path and backup paths of each module pair truly have redundancy capabilities, specifically including two parts: path independence verification and load sharing verification.

[0063] The specific steps for path independence verification are as follows: For each record in the path integration configuration, the system reads the primary communication address and all backup communication addresses. Based on the mapping relationship of these addresses in the network topology, it determines the set of physical nodes and the set of critical links that each address passes through. The set of physical nodes is the set of node numbers that undertake forwarding or processing functions on the path, and the set of critical links is the set of physical link numbers that carry communication on the path. Then, the system compares the set of physical nodes of the primary path and the set of physical nodes of the backup path one by one, and counts the number of overlapping nodes. At the same time, it compares the set of critical links of the primary path and the set of critical links of the backup path, and counts the number of overlapping links. When there is no overlap between the backup path and the primary path in the set of physical nodes and the set of critical links, or there is only no more than one overlapping element that does not affect fault isolation, it is determined that the backup path has sufficient redundancy in the topology. Otherwise, it is determined that the backup path cannot provide effective redundancy. In this case, the system will try to select a new backup address for the module pair in the backup address pool to build a backup path. If there are no available resources, the module pair is marked as having insufficient redundancy in the path integration configuration.

[0064] The specific steps of load sharing verification are as follows: Based on the bandwidth usage and real-time load information recorded in the module resource usage table, the system calculates the theoretical load sharing ratio for each main path and its backup paths. This ratio is calculated as follows: First, the carrying capacity of the main path and all backup paths is comprehensively evaluated based on the theoretical maximum bandwidth of their corresponding communication addresses and the current error statistics to obtain a carrying weight value. Then, the carrying weight of each path is divided by the sum of the carrying weights of all paths to obtain the load sharing ratio. A higher load sharing ratio indicates that the path is designed to handle more traffic. Subsequently, during the simulation or early stages of actual operation, the system collects the actual load sharing ratio of each path. By comparing the difference between the actual load sharing ratio and the theoretical load sharing ratio, if the difference is within a specified range, the load sharing is considered reasonable. If the difference exceeds the specified range, the system will appropriately adjust the priority of each path on that module under the dynamic priority adjustment rules of the communication topology adaptation scheme, gradually bringing the load closer to the target ratio. The specified range in path redundancy verification is determined by statistically analyzing historical operating data.

[0065] In the above process, during a period of stable system operation, the difference between the theoretical load-sharing ratio and the actual load ratio of each connection is calculated. The absolute values ​​of all differences are averaged to obtain an average difference value, which is used as the load-sharing deviation threshold. When the difference of a connection is less than or equal to the threshold, it is considered to meet the requirements; when the difference is greater than the threshold, it is considered to fail and requires adjustment. After path independence verification and load-sharing verification, the system makes necessary path adjustments or priority adjustments to modules that fail to meet the requirements until the main path and backup path of all critical module pairs are sufficiently independent in terms of topology and the load sharing is within the allowable range. At this point, the system integrates the path configuration and the adjusted communication topology adaptation scheme and applies them to the communication interface of the target end. This means that for each communication interface, the final determined new communication address, primary / backup path switching rules, dynamic priority adjustment rules, and data verification strategies are written, completing the update of the initial configuration of all interfaces. This state is the final communication interface operating environment. In this operating environment, each important connection not only has a verified address mapping, but also a reasonable resource allocation ratio calculated and a backup path confirmed by redundancy verification, thereby ensuring the reliability, recoverability, and load balancing of the communication connection during the subsequent NCCL migration and operation.

[0066] S6 includes obtaining the target-side multi-threaded communication logic from the interface runtime environment, activating the logic and integrating the state consistency verification results to obtain the activated communication logic; for the activated communication logic, updating the thread running parameters according to the module state log records to determine the updated parameter set; using the updated parameter set, combined with the verification results, judging the data link switching conditions based on the preset switching threshold to obtain the switching condition satisfaction; obtaining the switching condition satisfaction, extracting migration resources from the backup thread pool, and integrating the context migration state to construct a complete migration configuration; using the complete migration configuration, optimizing the target-side activation mechanism and integrating the parameter update process to obtain the complete context migration state.

[0067] In this embodiment, at the beginning of step S6, the target end has obtained the final communication interface runtime environment according to the aforementioned steps. This runtime environment records the corresponding module identifier, thread identifier, communication address, synchronization signal priority, primary / backup path information, and dynamic priority adjustment rules for each communication interface. The system first obtains the target end's multi-threaded communication logic from this runtime environment. Here, multi-threaded communication logic refers to the set of all threads participating in communication on the target end, their dependencies, calling order, and resource binding relationships. Specifically, the system iterates through all interface records in the communication interface runtime environment, and for each record, reads the thread identifier and corresponding module identifier bound to the interface. The system identifies the thread, its communication direction, communication address, and role in the synchronization flag. This information is grouped by thread identifier to construct a thread communication logic table. Each row in this table represents a thread, recording the module it belongs to, its bound communication address, its communication group, and the identifiers of other threads it depends on. This creates a structured description of the target-side multi-threaded communication logic. After obtaining the multi-threaded communication logic, the system needs to activate it and integrate the state consistency check results to obtain the activated communication logic. The specific process of activating the logic is as follows: First, based on the state consistency check results recorded for each module… The system uses consistency flags to mark modules as having consistent states, making them active and inactive. Modules marked as having inconsistent states are temporarily deactivated. The system then checks the module identifier for each row in the thread communication logic table. If a thread belongs to an active module, it is marked as a candidate for activation; otherwise, it is marked as a prohibited activation thread. The system further calculates an activation order number for each candidate thread based on synchronization signal priority and module dependencies. Specifically, for each candidate thread, the system extracts the difference between its synchronization signal priority value and the average parameter difference of its module during state consistency verification. The system prioritizes threads with higher synchronization signal priority and smaller average parameter differences, placing them at the top of the activation order. After sorting all candidate activation threads according to this rule, the system sends thread activation requests to the operating system sequentially, starting with the first thread in the sorted list. When activating each thread, the thread state is changed from ready to running, its bound communication address is configured in the corresponding communication interface structure, and an activated flag is written in the internal activation flag field. Threads that are not activated remain unchanged. The final thread communication logic, which only contains activated threads and records their order and dependencies, is the activated communication logic. This logic serves as the basis for the runtime environment in subsequent steps.After the communication logic is activated, the system updates the thread running parameters based on the module status log records to determine the set of updated parameters. The module status log records are the set of running history records generated for each module in the previous steps, which include fields such as event type, thread identifier, communication address, transmission delay, number of errors, and resource usage at different points in time for each module. The thread running parameters refer to the configurable parameters related to each thread during operation. In this embodiment, the thread running parameters include the thread running priority, the maximum number of concurrent transmissions allowed per thread, the send buffer size, the receive buffer size, the upper limit of the number of error retries, and the timeout length.

[0068] The update process is implemented as follows: The system reads the thread identifier of each activated thread one by one from the activated communication logic table. Then, it filters out all log entries corresponding to the thread identifier from the module status log record, sorts these log entries by timestamp from earliest to latest, and counts the total number of data units successfully sent, the total number of data units that failed or were retried, the latency value of each data unit from transmission to reception, and the number of error events within a certain time window. Based on these raw data, the system calculates the thread's average transmission latency, error rate, and throughput. The average transmission latency is calculated by adding the latency values ​​of all data units of the thread one by one during the observation period, and then dividing the total latency by the number of data units to obtain the average value. The error rate is calculated by dividing the number of error events of the thread during the observation period by the number of data units to obtain a decimal between 0 and 1. The throughput is calculated by dividing the total number of data bytes successfully transmitted by the thread during the observation period by the observation period length to obtain a value of bytes transmitted per unit time. The system updates the thread running parameters based on these three indicators. For example, if the average transmission latency of a certain thread is significantly higher than that of all threads... When the average transmission latency is high and the error rate is high, the system appropriately increases the maximum number of error retries for that thread and appropriately increases the timeout length to avoid frequent timeouts. When the throughput of a certain thread is much lower than the average throughput of all threads but the error rate is low, the system appropriately increases the maximum concurrent sending count and sending buffer size for that thread to improve utilization. When the error rate of a certain thread is consistently high and the average parameter difference of the state consistency of its module is large, the system lowers the running priority of that thread by one level to avoid affecting overall communication. All the above adjustments are made according to defined rules. For example, the system can set multiple intervals for each indicator. When the average transmission latency is higher than a certain fixed threshold and the error rate is higher than a certain fixed threshold, one set of parameter adjustments is executed. When it is in the middle interval, another set of adjustments is executed. When it is significantly better than the average level, it remains unchanged or the priority is appropriately increased. The updated running parameters of all active threads are stored in a parameter update table. This table is the set of updated parameters. Each row in the table corresponds to a thread and records the latest running priority, maximum concurrent sending count, sending buffer size, receiving buffer size, maximum number of error retries, and timeout length for that thread.

[0069] After obtaining the updated parameter set, the system uses the updated parameter set, combined with the verification results, to determine the data link switching conditions based on the preset switching threshold, thus obtaining the switching condition satisfaction level. The verification results here include the state consistency verification results and the stability verification results from the aforementioned communication topology adaptation scheme simulation test, collectively reflecting whether the current system has the conditions to perform data link switching. The specific judgment process is as follows: the system calculates a switching score for each activated thread. This switching score quantifies whether the thread is suitable to perform data link switching at the current moment. The switching score is calculated based on three sub-scores: state reliability score, performance improvement space score, and resource security score, all represented by integers from 0 to 100. The state reliability score is calculated as follows: if the module to which the thread belongs is marked as passed in the state consistency check and the communication path where the thread is located in the latest simulation test is marked as stable, then the thread is assigned a state reliability score of 100. If the path where the thread is located is stable in the simulation test but the average parameter difference value of the module to which it belongs is close to the preset threshold, then the state reliability score is set to 70. When the module to which it belongs is marked as failed or the path where the thread is located is unstable in the simulation test, the thread is not included in the current active set, and therefore its switching score will not be calculated in this step, thereby ensuring that the thread participating in the switching judgment itself has basic reliability.

[0070] The performance improvement space score is calculated as follows: The system compares the changes in the running parameters of each thread before and after the update. When the updated running parameters have a significant expected improvement in throughput and error rate compared to the original parameters, the thread is assigned a higher performance improvement space score. For example, when the updated configuration increases the theoretical throughput by more than a set proportion and the error rate is predicted to decrease, the performance improvement space score is set to a specific value between 80 and 100. When the improvement is in the medium range, the score is set between 50 and 79. When the improvement is small or the updated parameters are only used for stability and not for improving performance, the score is set below 50.

[0071] The resource security score is calculated as follows: The system reads the current processor utilization, memory utilization, and network bandwidth utilization of the module to which the thread belongs from the module resource utilization table. When the utilization of each resource is lower than the corresponding resource's preset security limit in the system configuration, the resource security score is set to a higher value. When the utilization of a resource is close to the limit, the score is reduced proportionally. When any resource exceeds the limit, the thread is not suitable as a switching target, and the system removes it from the switching judgment list and no longer participates in this round of judgment. For each thread included in the judgment, the system adds up the thread's three sub-scores sequentially to obtain a total score, and then divides the total score by 3 to obtain a switching score between 0 and 100. When the total score is not divisible by 3, the decimal part of the division result is discarded, and only the integer part is retained. The system then calculates a preset switching threshold for all threads participating in the judgment. Specifically, the switching scores of all threads are summed to obtain a total score. This total score is then divided by the number of threads participating in the judgment to obtain an average switching score. This average switching score is used as the preset switching threshold, representing the average level of all threads suitable for switching at the current moment. The system then compares the switching score of each thread with the preset switching threshold. When a thread's switching score is greater than or equal to the preset switching threshold, the thread is considered to meet the data link switching conditions and is marked as a condition-met thread. When the switching score is less than the preset switching threshold, the thread is considered temporarily unsuitable for switching and is marked as a condition-unmet thread. The system counts the number of condition-met threads and the total number of threads participating in the judgment. The number of condition-met threads is divided by the number of threads participating in the judgment to obtain a decimal between 0 and 1. This decimal is then multiplied by 100 and rounded down to obtain a percentage integer. This percentage integer is used as the switching condition satisfaction rate, representing the proportion of threads currently meeting the switching conditions out of all participating threads. The system also retains a detailed list of condition-met threads for later use. After obtaining the switching condition satisfaction level and the list of threads that meet the condition, the system extracts migration resources from the standby thread pool, integrates the context migration state to construct a complete migration configuration. The standby thread pool is a set of standby threads that are pre-established on the target side, which are not participating in the current communication but have been initialized. Each standby thread is assigned a unique thread identifier, independent stack space, basic running parameters and an allocable communication interface binding slot when it is created, and is in a waiting state and does not participate in actual data transmission and reception. The standby thread pool also records a standby priority for each standby thread. The standby priority is determined during system initialization based on the performance of the processor core and the availability of resources. The higher the standby priority value, the more suitable the standby thread is as a migration target.Migrating resources refer to the set of standby threads and their related resources selected from the standby thread pool to take over the context of the currently active thread. These include the thread execution entity and buffers, retry counters, and status record structures that can be allocated to the thread.

[0072] The specific extraction process is as follows: The system first counts the number of threads that meet the conditions and counts the number of idle backup threads in the backup thread pool. When the number of backup threads is greater than or equal to the number of threads that meet the conditions, a backup thread is allocated to each thread that meets the conditions. The allocation strategy is to sort the threads that meet the conditions from largest to smallest according to their switching scores, and sort the backup threads from largest to smallest according to their backup priorities. Then, the thread with the highest switching score is allocated to the backup thread with the highest backup priority in order. The correspondence is recorded in a migration mapping table. When the number of backup threads is less than the number of threads that meet the conditions, the system only allocates to a few threads with the highest switching scores, and their number is equal to the number of backup threads. The remaining threads that meet the conditions are not migrated in this round and are processed in the next round when resources are sufficient.

[0073] After allocating backup threads, the system merges the original context migration state with the current migration mapping. The context migration state is the set of states progressively built for each thread in the preceding steps, including the thread identifier at the source end, the current transmission interruption recovery point, the synchronization tag decoding result, lock resource status, current communication address, and priority information. For each pair of source and backup threads in the migration mapping table, the system establishes a migration configuration record. This record contains all the context migration state information of the source thread, along with the thread identifier of the backup thread, its bound new communication address, and updated runtime parameters. If necessary, a migration order number is assigned to the migration pair, increasing sequentially from largest to smallest based on the source thread's switching score, indicating the migration execution order. All migration configuration records are then summarized to form a complete migration configuration. This configuration details which source threads need to be migrated to which backup threads, which context fields need to be copied for each migration, what runtime parameters should be used during the migration process, and the binding relationship between threads and communication interfaces after the migration is complete.

[0074] After the complete migration configuration is generated, the system adopts the complete migration configuration, optimizes the target activation mechanism and integrates the parameter update process, and finally obtains the complete context migration state. Specifically, the system first adjusts the target thread activation mechanism, expanding the original activation order based only on module status and synchronization signal priority to simultaneously consider the migration order number in the migration configuration and the fulfillment of switching conditions.

[0075] The specific adjustments are as follows: When activating threads, priority is given to activating threads that have already been allocated backup threads in the migration configuration and have the smallest migration order number. For these threads, a context switch is immediately performed during activation, copying their source context data to the corresponding backup thread's runtime environment according to the field definitions in the migration configuration. After copying, the old thread's state is marked as terminated, and the backup thread's state is marked as running, thus achieving seamless switching. For activated threads that were not allocated backup threads in this migration round, their original activation method remains unchanged. Simultaneously, the system integrates the updated parameter set into the entire parameter update process. Specifically, before each migration execution, the running parameters of the corresponding thread in the parameter update table are written into the migration configuration record. When the backup thread is actually activated, these parameters are synchronously written into the backup thread's runtime control structure, ensuring that the migrated thread immediately runs with the new parameter configuration. After the migration execution is completed, the system continues to collect module status log records according to a predetermined period and refreshes the average transmission latency, error rate, and throughput using the same calculation method, thereby periodically updating the thread runtime parameter table. This ensures that any subsequent possible migrations or load adjustments are always based on the latest runtime status.

[0076] After this series of activation mechanism optimizations and parameter update integrations, the system re-counts the current context state of all threads that have completed migration or remained unchanged, forming a new context migration state set. Each record in this set clearly identifies the physical execution entity the thread is currently in, the bound communication address, the transmission interruption recovery point, the synchronization flag content, the lock resource status, the running parameters, and whether it has undergone migration. When all threads that should be migrated have completed the switch according to the migration configuration and all threads have passed the stability test in the new running environment, the current context migration state set is determined as the complete context migration state.

[0077] like Figure 1 As shown, Figure 1 On the left is a single machine with dual cards communicating based on shared memory on the CPU, which can have two types: host address and device address; Figure 1 On the right is GPU Direct P2p (Peer-to-Peer) communication between two GPUs on a single machine via the PCIe bus, which only requires the device address.

[0078] Because GPU topology changes may occur before and after the migration, these changes can lead to inconsistencies in the NCCL data link type selection, potentially causing... Figure 1 The situation is as follows: Before the migration, communication was SHM; after the migration, it became P2P communication. Because the host address type existed before the migration, but the corresponding address type no longer exists after the migration and cannot be recovered, this situation will cause the migration to fail.

[0079] Multithreading before and after migration introduces data synchronization issues: During the initialization phase of the NCCL program, multiple threads may concurrently allocate video memory or share memory. Recording and restoring this address information before and after migration requires ensuring consistency across these threads, which is challenging. Simply using "playback-based migration" techniques is insufficient to avoid multithreaded data synchronization problems. This invention aims to prevent multithreading from introducing issues in NCCL's hot migration tasks.

[0080] The synchronous state of the program cannot be guaranteed before migration: NCCL programs have many intermediate states during operation. Simply using "playback-based migration" technology is insufficient to restore the program to its intermediate states and allow it to continue execution after migration. This invention aims to address this problem by modifying the NCCL resource allocation method and introducing monitoring mechanisms to ensure synchronization during migration.

[0081] Therefore, in one specific embodiment, the present invention also provides a resource pool-based NCCL migration method, comprising the following steps: The first step is to pre-allocate a resource pool containing six types of address resources for each GPU device before the NCCL program initializes multi-threaded operations.

[0082] The second step is to modify the NCCL resource allocation logic so that the data link establishment process obtains address resources from the resource pool.

[0083] The third step involves implanting a control module into each user thread to hook NCCL API operations and monitor thread synchronization status. The control module intercepts NCCL API calls using function hook technology and marks the thread synchronization status after asynchronous operations are completed. Here, "Hook" refers to a mechanism in computer programming that allows a program to insert custom code when a specific event occurs, enabling the interception, modification, or extension of that event. This concept is commonly used in software development and system programming. In this patent, "Hook" specifically refers to function hooks. A function hook involves modifying the address or instructions of a target function to point it to a custom function, allowing additional logic to be executed before or after the target function. This technique is often used for debugging, performance analysis, or modifying function behavior at runtime.

[0084] The fourth step involves periodically checking all control modules through the migration control thread. When all threads meet the synchronization conditions, the migration is triggered. The conditions for triggering the migration are that the control modules of all user threads report the synchronization completion signal, and there are no unreleased intermediate state resources in NCCL.

[0085] Step 5: During migration execution, retain the source Context data and restore the resource pool address mapping relationship on the target side.

[0086] NCCL migration design structure diagram as follows Figure 2 As shown. To avoid needing to restore the intermediate NCCL state, the NCCL needs to be in a completed synchronized state when the migration is initiated. However, there may be multiple threads in the user program, so the migration can only proceed after the asynchronous operations of all threads are completed. Therefore, this invention embeds a control module in each thread, hooks the NCCL API operation, and notifies the control module within the thread to perform the operation when the thread meets the synchronization requirements. The migration control thread periodically checks the contents of the control module, and triggers the migration operation when all threads meet the migration conditions. This ensures that all user threads are in an operable synchronized state when each migration is initiated.

[0087] NCCL resource pool structure design diagram as follows Figure 3 As shown. Figure 3 In the diagram, the left image shows the original resource allocation method of NCCL, and the right image shows the design method of this invention. It can be seen that... Figure 3 This invention modifies NCCL in two ways: 1. Different resource allocation locations: The resource allocation location is shifted to before the start of multithreading and allocated uniformly.

[0088] 2. Different types of resource allocation: This invention allocates all resource types at once, whereas NCCL previously only allocated one type of address resource between two GPUs.

[0089] like Figure 4 The diagram shown illustrates the specific modifications made to NCCL in this invention. Figure 4 As can be seen, a resource pool design is introduced between NCCL obtaining the Unique ID within the group and establishing the bootstrap network. To prevent data errors caused by switching between different contexts, this invention allocates six resource pools for each GPU device. During the NCCL data link establishment process, resource allocation is also changed to obtain resources from these resource pools.

[0090] Depending on the type of resources allocated, resource pools can be designed in the following three ways: Type A resource pool: It consists of three independent sub-pools: large, medium, and small. Each sub-pool divides resource blocks according to fixed address intervals.

[0091] Type B resource pool: Pre-occupies contiguous address space, and the mapping is divided and mapped as needed at runtime.

[0092] Type C resource pool: Combines Type A and Type B structures, and sets a threshold to distinguish between short-interval resource pools and long contiguous address spaces.

[0093] like Figure 5 As shown, resource pool A is composed of three resource pools: large, medium, and small. And it can be seen that... Figure 5 The arrows in the diagram point to different index positions, which also indicates that the three resource pools are independent and do not interact, and resources can be allocated from them separately.

[0094] Resource pool 'a' is used in situations where resource allocation based solely on address partitioning is not permissible. Examples include memory allocation in the CUDA runtime library, where each sub-pool's resource index is independent and does not interact with others.

[0095] like Figure 6 As shown, resource allocation involves first occupying a whole block of addresses that will be needed in the future, and then continuously allocating smaller blocks of address resources according to usage needs.

[0096] Resource pool b is used when allocating shared memory on the host. For example, mmap can allocate a large anonymous address space first, and then map a certain part of the address space to a disk file when it is used later.

[0097] like Figure 7 As shown, resource pool c combines design methods a and b. Small address resource pools can only allocate some short-interval address resources, while large resource pools can allocate address resources longer than a certain threshold.

[0098] The use case for resource pool c is when you need to allocate low-level memory type addresses for the CUDA driver. Sometimes NCCL allocates short-interval addresses and sometimes long-interval addresses. If design method b is used, the CUDA driver does not allow this design, so design method c can be used to allocate them separately.

[0099] Furthermore, the resource pool contains six types of address resources, specifically: Host address based on CPU shared memory; Device address for GPU Direct P2P communication; CUDA Driver long-interval memory addresses; CUDA Driver short-interval memory addresses; Mmap mapping address; Bootstrap network communication address.

[0100] In summary, using this invention for NCCL thermal migration will solve the following three problems: 1. Ensure consistent address types before and after migration: The main purpose of setting up multiple resource pools in this invention is to solve the problem of different address types caused by different topologies before and after migration. Since all possible future address resources are allocated during initialization, there is no need to worry about different address types introduced by different topologies.

[0101] 2. Avoids data synchronization issues caused by multi-threading before and after migration: This patented invention completes the allocation of address resources before the NCCL program starts multi-threading. Allocation is done once, and hooking occurs once, so there's no need to worry about new problems introduced by multi-threading.

[0102] 3. Ensure the program is in a synchronized state before migration: The NCCL program will have many intermediate states during operation. By monitoring the migration control thread and pre-allocating resources from multiple resource pools, it can be ensured that the program is in a synchronized state during migration, and NCCL has already allocated all resources.

[0103] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A resource pool based NCCL migration method, characterized in that, include: S1. By scanning the multi-threaded runtime environment of the NCCL communication program based on the resource pool at the source end, obtain thread identification records, synchronization timestamp markers and thread state information from the resource pool; generate thread state snapshots in combination with data packet transmission progress, construct a data transmission state file containing transmission interruption recovery points and synchronization signal priorities, and determine the initialized synchronization marker dataset; S2. Based on the initialized synchronization mark dataset, transmit the thread state snapshot and data check code value to the target end, decode the synchronization mark using the inheritance mark parsing rules, generate the control module state cache of the target end, and obtain the preliminary synchronization mark inheritance result. S3. Based on the preliminary synchronization mark inheritance results, adjust the thread lock resource status in the target control module's state cache according to the synchronization mark update frequency and state transition triggering conditions, handle mark conflicts in conjunction with inheritance conflict resolution logic, and determine the updated state consistency verification results. S4. Based on the state consistency verification results, obtain the target end module state log records and module resource occupancy table, match the source end synchronization signal priority and transmission interruption recovery point, remap the target end communication address resources, and obtain the adjusted communication topology adaptation scheme.

2. The resource pool based NCCL migration method of claim 1, wherein: S1 includes: By scanning the multi-threaded runtime environment of the NCCL communication program based on the resource pool at the source end, thread identification records, synchronization timestamp markers, and thread state information are obtained from the resource pool. The resource pool contains multiple types of address blocks, such as shared memory addresses, long and short interval GPU memory segments, P2P communication addresses, and network mapping addresses, for NCCL communication. It is divided into multiple independently indexable sub-pools at fixed intervals. The sub-pool division process involves evenly dividing the overall address space of the resource pool into fixed-size blocks, allocating a specific type of address to each block to support independent access, and obtaining a set of thread state information. For the set of thread state information, a thread state snapshot is generated by combining the data packet transmission progress. The thread state snapshot captures dynamic changes by recording the current transmission position and interruption point. The process of capturing dynamic changes is to compare the difference between the transmission progress and the timestamp to identify the change point and determine the transmission interruption recovery point. Starting from the transmission interruption recovery point, a data transmission status file containing the transmission interruption recovery point and the priority of the synchronization signal is constructed. The construction process involves integrating the recovery point and priority data into a structured file format that supports fast querying. The integration into the structured file format is achieved by matching the recovery point to the priority value item by item to form key-value pairs, thus obtaining the data transmission status file. The priority of the synchronization signal in the data transmission status file is obtained, and the priority is sorted by combining the sub-pool independent index. The sorting process uses a preset threshold to compare the priority values ​​to arrange the order. If the priority is higher than the threshold, it is placed in the front row, and the sorted priority sequence is obtained. Based on the sorted priority sequence, the network mapping address and P2P communication address are merged to generate an initialization tag. The generation process involves mapping the address to the corresponding position in the sequence to form a complete dataset and determining the initialization synchronization tag dataset.

3. The resource pool based NCCL migration method of claim 1, wherein: S2 includes: Obtain thread state snapshots and data checksum values ​​from the initialized synchronization tag dataset, send the thread state snapshots and data checksum values ​​through the target end transmission process, and obtain the snapshot set after transmission; For the snapshot set after transmission, the synchronization marker is decoded using the inherited marker parsing rule. The inherited marker parsing rule performs bit-by-bit matching by comparing the marker bit sequence to generate the control module state cache at the target end, and obtains the decoded cache data. Based on the decoded cached data, the checksum is dynamically adjusted by integrating the preset priority sorting sequence. The dynamic adjustment of the checksum is achieved by adding or subtracting to correct the difference between the checksum value and the priority value, thereby determining the adjusted priority sequence. By combining the adjusted priority sequence with the initialization tag fusion to verify cache consistency, the initialization tag fusion performs consistency verification by merging the tag dataset with the corresponding items in the sequence to obtain the preliminary synchronization tag inheritance result.

4. The resource pool based NCCL migration method of claim 1, wherein: S3 includes: The update frequency value and state transition trigger condition are obtained from the initial synchronization mark inheritance result. The frequency matching set is obtained by comparing the update frequency value with the preset threshold. For the frequency matching set, the thread lock resource state in the state cache of the target control module is adjusted according to the state transition trigger condition. The adjusted lock state data is generated by comparing the lock resource state with the allocation threshold for verification. Obtain the adjusted lock state data, combine the inheritance conflict resolution logic to process the marked conflict, and if the conflict value exceeds the preset threshold, execute the priority sequence correction. Determine the conflict processing sequence by comparing the conflict value with the sequence item. The synchronization marker is decoded by the conflict handling sequence fusion parsing rules. The parsing rules generate an updated control module state cache by matching the marker bit sequence bit by bit, and obtain the cache update set. Perform consistency checks on the cached update set, compare the data checksum values ​​with the initialization flags, and determine the consistency check results of the updated state.

5. The resource pool based NCCL migration method of claim 1, wherein: S4 includes: Based on the state consistency verification result, the module state log record and module resource usage table are obtained from the target module. The state consistency verification is performed by comparing the differences between the source and target module parameters. If the difference is less than a preset threshold, the verification is determined to be successful. The module state log record is used to record the module's running history and the module resource usage table is used to display the resource usage. For the module status log records and module resource usage table, match the synchronization signal priority and transmission interruption recovery point of the source end. The synchronization signal priority is sorted according to the urgency of the signal, and the transmission interruption recovery point is restored by recording the interruption position, so as to obtain the matching priority sequence.

6. The resource pool based NCCL migration method of claim 5, wherein: S4 further includes: Based on the matched priority sequence, the target end communication address resources are remapped. The remapping adopts the address reallocation method, which converts the old address to the new address to optimize the connection. An abnormal state repair service is introduced to repair potential faults by analyzing the module status log records and determine the address configuration after mapping. Based on the mapped address configuration, an adjusted communication topology adaptation scheme is constructed. The communication topology adaptation scheme integrates address resources and priorities, introduces dynamic priority adjustment services to modify priorities according to real-time load, and determines that if the load exceeds a threshold, low-priority signals are reduced to obtain a preliminary adaptation scheme. A preliminary adaptation scheme is obtained, and final verification is performed. The stability of the preliminary adaptation scheme is tested through simulated transmission to obtain the adjusted communication topology adaptation scheme.

7. The resource pool based NCCL migration method of claim 1, wherein, It also includes S5, which, based on the adjusted communication topology adaptation scheme, loads the initialization configuration of the target end's communication interface, verifies the accuracy of the address mapping by combining the data checksum value, and if the verification results show inconsistencies, triggers the resource distribution reallocation process to determine the final communication interface operating environment, specifically including: According to the topology adaptation scheme, the backup address pool is obtained from the target end, the initial configuration of the communication interface is loaded, and the accuracy of the address mapping is verified by comparing the difference between the code values ​​before and after the mapping, and the verification result is obtained. If the verification results are inconsistent, spare resources are extracted from the backup address pool, triggering a resource distribution redistribution process. The address configuration after redistribution is determined by adjusting the resource allocation ratio. 8.The resource pool based NCCL migration method of claim 7, wherein: The S5 also includes: Obtain the redistributed address configuration, integrate redundant links in the backup address pool, construct backup paths for communication interfaces by prioritizing links, and obtain the path integration configuration; From path integration configuration, the application of the adjusted communication topology adaptation scheme, the fusion of redundant links and the optimization of connections through path redundancy verification, the final communication interface operating environment is determined.

9. The NCCL migration method based on a resource pool according to claim 7, characterized in that, It also includes S6, which, through the final communication interface runtime environment, activates the target-side multi-threaded communication logic, updates thread runtime parameters based on state consistency verification results and module state log records, determines whether the seamless data link switching conditions are met, and obtains the complete context transition state, specifically including: The target multi-threaded communication logic is obtained from the interface runtime environment. The activated communication logic is obtained by activating the logic and integrating the state consistency verification results. For the communication logic after activation, update the thread running parameters based on the module status log to determine the set of parameters to be updated.

10. The resource pool based NCCL migration method of claim 9, wherein: S6 further includes: By updating the parameter set and combining the verification results with the preset switching threshold, the data link switching conditions are determined, and the degree of satisfaction of the switching conditions is obtained. Get the switching condition satisfaction level, extract migration resources from the standby thread pool, and build a complete migration configuration by integrating the context migration state; By adopting a complete migration configuration, optimizing the target activation mechanism, and integrating the parameter update process, a complete context migration state is obtained.

Images