Multi-thread parallel redundancy fault-tolerant method based on compilation layer

Abstract

The invention relates to a multi-thread parallel redundancy fault-tolerant method based on a compilation layer. The invention relates to the technical field of embedded processor design. The method comprises the following steps: determining thread division and an SoR region core; packaging an SoR region related fault-tolerant function library, packaging a core fault-tolerant function into a header file, and ensuring that a library file contains a tool function strongly associated with the SoR region; matching the compiler with the tool chain; marking and automatically identifying the source program; automatically identifying and supplementing the ROSE compiler; compiling the SoR region and generating a dual-thread code; performing double-thread parallel execution and check point interaction; and redundant fault-tolerant processing and flow continuation are carried out. The method does not depend on a specific hardware platform, and the problem of poor portability of a traditional hardware redundancy technology or a fault-tolerant technology depending on a specific hardware architecture is effectively avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of embedded processor design, and is a multi-thread parallel redundancy fault-tolerant method based on a compilation layer. BACKGROUND

[0002] In embedded systems, reliability is one of the core indicators. Although traditional hardware redundancy technology (such as triple modular redundancy) can improve system reliability, it significantly increases cost, volume and power consumption, and is difficult to meet the lightweight requirements of embedded scenarios.

[0003] Existing software redundancy technology has many limitations: N-text method requires multiple independent programs to run in parallel on different machines and vote on the results, which consumes a lot of resources and relies on multiple hardware platforms; the recovery block method implements fault tolerance by dynamically replacing the backup program block, which is complex to design and has low flexibility; fault-tolerant technology based on the operating system or application layer often relies on specific hardware architecture, has poor portability, and increases system complexity.

[0004] In addition, fault-tolerant models based on processor layer SMT (Simultaneous Multithreading) and CMP (Chip Multiprocessors) structure (such as SRT, CRT) can achieve fault tolerance, but they rely on hardware design and have problems such as poor portability, high cost, and limited adaptability. Therefore, there is an urgent need for a fault-tolerant solution that is completely based on the software layer, does not rely on specific hardware, is easy to implement, and has low cost, to make up for the shortcomings of existing technology. SUMMARY

[0005] To solve the problems of high hardware redundancy cost, software redundancy dependence on hardware or complex implementation, and poor portability in the prior art, the present application provides a parallel redundancy multi-thread fault-tolerant method based on a compilation layer, which aims to improve the fault-tolerant capability of embedded systems through software-level redundancy design without increasing hardware cost, while simplifying the implementation process and enhancing portability.

[0006] The present application provides the following technical solutions: A multi-thread parallel redundancy fault-tolerant method based on a compilation layer, the method comprising the following steps: Step 1: determine thread division and SoR area core; Step 2: encapsulate SoR area related fault-tolerant function library, encapsulate core fault-tolerant function as a header file, and ensure that the library file contains tool functions that are strongly associated with the SoR area; Step 3: perform compiler and tool chain adaptation; Step 4: annotate and automatically identify the source program; Step 5: automatically identify and supplement the ROSE compiler; Step 6: Compiling SoR region and generating dual-thread code; Step 7: Dual-thread parallel execution and checkpoint interaction; Step 8: Redundancy fault-tolerant processing and flow continuation.

[0007] Preferably, the main thread serves as the main entry of program execution, covering the complete business logic, both repeatable operations and non-repeatable operations; The redundancy thread, as a fault-tolerant verification carrier, focuses on the synchronization and comparison of core logic, executes repeatable operations consistent with the main thread, and performs result comparison at key nodes; The SoR region specifically contains "repeatable operations" that need to be synchronized by dual threads, ensuring that the redundancy thread replicates the core logic of the main thread and excludes non-repeatable operations to avoid invalid redundancy.

[0008] Preferably, sor_mark(): used to mark the start and end of "repeatable operations" during the compilation phase, explicitly define the boundaries of the SoR region, and support the compiler to identify the instructions and variables that need to be copied; thread_sync(): implements dual-thread data synchronization, provides an interface for the main thread to write "repeatable operation variable" to the shared buffer, and provides an interface for the redundancy thread to read the main thread variable from the buffer; checkpoint_trigger(): checkpoint trigger function, controls the dual-thread to synchronize and pause at the checkpoint position, ensuring consistent comparison timing; result_verify(): result comparison function dedicated to the redundancy thread, supporting bit-by-bit comparison and Hash value comparison of original data.

[0009] Preferably, integrate mthread.h into the compiler static link library that supports embedded multi-core platforms, ensuring that the compiler can recognize and parse the following compilation directives: #pragma sor_start and #pragma sor_end: used to manually mark the start and end of the SoR region in the source program; #pragma checkpoint: used to mark the checkpoint position; Configure the ROSE compiler as an auxiliary tool to automatically analyze the semantic logic of the source program, identify implicit repeatable operations, and automatically insert #pragma sor_start and #pragma sor_end, ensuring that the SoR region completely covers the logic that needs to be synchronized by dual threads, and supplements the omissions of user manual annotations.

[0010] Preferably, wrap repeatable operations in source program with #pragma sor_start and #pragma sor_end to explicitly include SoR region; Insert #pragma checkpoint at key nodes within SoR region; Non-repeatable operations do not need to be wrapped, and are executed exclusively by the main thread by default, without entering the SoR region.

[0011] Preferably, perform syntax analysis on the source program to automatically identify code segments that meet the "repeatable operation" characteristics but are not explicitly labeled, and generate supplementary #pragma sor_start and #pragma sor_end to ensure that there is no omission in the SoR region; Perform type analysis on variables within the SoR region, automatically label key variables that need to be compared, and generate #pragma compare_var statements to avoid user manual omission of core variables.

[0012] Preferably, main thread code generation: completely retains the logic of the source program, and embeds the thread_sync() function within the SoR region to ensure that repeatable operation variables are written to the shared buffer in real time during execution; Insert checkpoint_trigger() at the #pragma checkpoint label, which triggers the logic of "pause execution → write current variables to buffer → enter blocked waiting" when executed; Redundant thread code generation: only extract repeatable operation code within the SoR region, and ensure complete synchronization with the main thread's repeatable operation through the sor_mark() function; Similarly, insert checkpoint_trigger() at the #pragma checkpoint label, which triggers the logic of "pause execution → read main thread variables from shared buffer → call result_verify() for comparison" when executed.

[0013] Preferably, thread startup and initial synchronization: the operating system schedules the main thread and redundant thread to start on different cores in parallel, and completes initial data synchronization through the thread_sync() function to ensure that both threads start execution from the same state; Checkpoint triggering and data comparison: when both threads execute to the #pragma checkpoint label, the main thread writes the current repeatable operation variable values to the shared buffer through checkpoint_trigger(), and then enters a blocked waiting state; The redundant thread synchronization pause reads the variable value of the main thread from the buffer through thread_sync(), calls result_verify() to compare it with the result of the repeatable operation executed by itself, if the data amount is reduced, directly compares bit by bit; if the data amount is increased, the MD5 algorithm is automatically called to generate a hash value, and the original data comparison is replaced by comparing the 128-bit hash value, reducing the amount of operation.

[0014] Preferably, the driving layer structure is an array structure for compensating skin curvature distortion by beam synthesis.

[0015] A computer readable storage medium has a computer program stored thereon, and the program is executed by a processor to implement a multi-thread parallel redundancy fault-tolerant method based on a compilation layer.

[0016] A computer device includes a memory and a processor, the memory stores a computer program, and the processor implements a multi-thread parallel redundancy fault-tolerant method based on a compilation layer when executing the computer program.

[0017] The present application has the following beneficial effects: In a first aspect, the fault-tolerant library file is designed and integrated, the fault-tolerant processing function is packaged in the form of a library file (.h), and is added to the static link library of a compiler, which can be any compiler supporting an embedded multi-core platform, the user can manually add variables to be compared in an application program, and set checkpoints and fault injection points at any time, and can also analyze fault-tolerant variables by means of a ROSE compiler, and add fault-tolerant compilation guidance statements to the source program to automatically set checkpoints and inject transient faults, through such design and integration, basic support is provided for subsequent fault-tolerant processing.

[0018] In a second aspect, redundant threads are generated and tasks are allocated, a redundant thread generation technology based on a compilation layer is adopted, a main thread is used as a program entrance, a Leading thread and a Trailing thread are generated, the Leading thread completes all non-replicated operations and replicated operations, the Trailing thread completes replicated operations and comparison of execution results, the model uses the concept of a replication area, division of a SoR (Sphere of Replication) area is based on instruction types and variable attributes, and it is determined which instructions and variables should be divided into the SoR, and which are non-replicated operations and variables, the main body is the Leading thread and the Trailing thread, the hardware platform can be a single core or a multi-core, no additional hardware needs to be added, and communication and synchronization between cores are realized based on software.

[0019] The third aspect, based on the foregoing redundancy model, realizes a checkpoint-based error detection mechanism, the main thread and the trailing thread set a checkpoint at the same synchronization point, before setting the checkpoint, the user adds the variable to be compared, the main thread enters a synchronous waiting state at the checkpoint, the trailing thread compares the execution result of itself with the main thread, if the result is consistent, the current thread state and the value of the variable are backed up, the main thread is awakened to continue to execute downward, if the result is inconsistent, it is determined that it is a transient fault, the variable value of the main thread and the trailing thread is restored by using the backup last checkpoint data, the last checkpoint is returned to re-execute until the program ends.

[0020] The fourth aspect, when the memory amount to be compared is large, a Hash algorithm can be used to save comparison time, the Hash algorithm maps an arbitrary length binary value to a fixed length smaller binary value, that is, a Hash value, which has key features such as one-wayness and collision resistance, and can ensure that different inputs obtain different mapping values, therefore, when a large amount of memory is compared, an MD5 algorithm can be used for Hash, the MD5 algorithm has an advantage in speed, it does not use a DES encryption algorithm, but uses simple bit operations, can fully utilize the parallel processing capability of modern processors, and the data transmission amount is small during the calculation process, only 128 bits, the transmission speed in memory and cache is fast, and the comparison amount is reduced by comparing the Hash values.

[0021] The fifth aspect, when a source program needs to be fault-tolerant, first, link the fault-tolerant header file (mthread.h) of the compiler, the source program is copied into two parts for redundant execution, that is, the main thread and the redundant thread, they set a checkpoint at the same synchronization point, the main thread waits at the checkpoint, the redundant thread performs a comparison operation, according to the comparison result, the main thread is awakened to continue to execute after backup or recovery, after the fault-tolerant processing is completed, the compiler backend is entered, an executable file is generated to end the program, the whole process is realized based on software, does not depend on specific hardware, has strong portability, and can verify the feasibility of multi-thread fault-tolerance in an embedded multi-core platform.

[0022] Compared with the prior art, the technical effects and advantages of the present application are that: 1. In the present application, since the software implementation is completely based on the compilation layer, does not depend on specific hardware platforms, whether it is a single-core or a multi-core embedded processor, without the need for additional modification or the addition of special components to the hardware, any compiler of the embedded multi-core platform can be adapted and supported, the problem of poor portability existing in the traditional hardware redundancy technology or the fault-tolerant technology depending on specific hardware architecture is effectively avoided, and the present application can be flexibly applied to different embedded system environments and has strong portability.

[0023] 2. In the present application, without adding additional hardware devices, compared with the traditional three-mode redundancy and other hardware redundancy technologies, the cost, volume and power consumption burden of the system are fundamentally reduced; at the same time, compared with the high resource consumption of N text method which needs multiple machines to run different programs, and the complex implementation of recovery block method which dynamically replaces program blocks, the present application embeds fault-tolerant mechanism through the compilation layer, encapsulates fault-tolerant processing function as a library file and integrates it into the compiler, which simplifies the complexity of system design, reduces the dependence on hardware resources and running environment, and significantly improves the economy and practicability of the scheme.

[0024] 3. In the present application, in terms of fault-tolerant efficiency and reliability, through the checkpoint-based error detection mechanism, transient faults can be detected in time and quickly recovered using backup data, ensuring that the program can be traced back to the correct state for continuous execution when an exception occurs, effectively ensuring the continuous and stable operation of the system; at the same time, for a large number of data comparison scenarios, MD5 and other Hash algorithms are used, which greatly reduces the amount of data comparison and transmission overhead by taking advantage of their fast calculation and fixed length hash value characteristics, and further improves the efficiency of fault-tolerant processing by combining the parallel processing capability of modern processors, balancing reliability and execution performance.

[0025] 4. In the present application, in terms of flexibility and adaptability, the user can manually set the variables to be compared, checkpoints and fault injection points, and at the same time, with the help of ROSE compiler, fault-tolerant guidance statements can be automatically analyzed and inserted, taking into account the accuracy of manual intervention and the convenience of automatic processing, which can meet the fault-tolerant needs of different application scenarios; and this technology is not only suitable for single-core processor environment, but also can realize thread parallel execution on multi-core platform, without the need to adjust the hardware architecture, which enhances the application range of the scheme. BRIEF DESCRIPTION OF DRAWINGS

[0026] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or prior art description. Obviously, the drawings described below are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0027] Fig. 1 The figure shows the multi-thread scheduling model based on compilation of the present application; Fig. 2 The figure shows the fault-tolerant structure based on compilation of the present application; Fig. 3 The figure shows the error detection and fault-tolerant process of the checkpoint of the present application. DETAILED DESCRIPTION

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

[0029] The present application will be described in detail below with reference to specific embodiments. Embodiment one: According to Figs. 1 to 3 As shown in the drawings, the specific optimization technical solution adopted by the present application to solve the above technical problems is: the present application relates to a multi-thread parallel redundancy fault-tolerant method based on a compilation layer.

[0031] The present application provides a multi-thread parallel redundancy fault-tolerant method based on a compilation layer, which comprises the following steps: Step 1: determine thread division and SoR area core; Step 2: encapsulate SoR area related fault-tolerant function library, encapsulate core fault-tolerant function as a header file, and ensure that the library file contains tool functions with strong association with the SoR area; Step 3: perform compiler and tool chain adaptation; Step 4: mark and automatically identify the source program; Step 5: automatically identify and supplement the ROSE compiler; Step 6: SoR area compilation and double-thread code generation; Step 7: double-thread parallel execution and checkpoint interaction; Step 8: perform redundancy fault-tolerant processing and process continuation. Embodiment two: The difference between the second embodiment of the present application and the first embodiment is only that: The main thread is the main entrance of program execution, which completely covers the business logic, and performs both repeatable operations and non-repeatable operations; The redundant thread is a fault-tolerant verification carrier, which focuses on the synchronization and comparison of core logic, performs repeatable operations identical to the main thread, and performs result comparison at key nodes; The SoR area specially contains "repeatable operations" that need to be synchronized by double threads, ensures that the redundant thread replicates the core logic of the main thread, and excludes non-repeatable operations to avoid invalid redundancy. Embodiment three: The difference between the third embodiment of the present application and the second embodiment is only that: sor_mark(): used to mark the start and end of "repeatable operations" in the compilation phase, to explicitly define the boundary of the SoR area, and to support the compiler to identify the instructions and variables that need to be copied; thread_sync(): Realize double-thread data synchronization, provide the interface of "repeatable operation variable write shared buffer" for main thread, and provide the interface of "read main thread variable from buffer" for redundant thread; checkpoint_trigger(): Checkpoint trigger function, control double thread to pause at checkpoint position, ensure the consistency of comparison opportunity; result_verify(): Result comparison function for redundant thread, support original data bit-by-bit comparison and Hash value comparison. Specific embodiment four: The difference between the embodiment four and the embodiment three is only that: Integrate mthread.h into the compiler static link library supporting embedded multi-core platform, ensure that the compiler can recognize and analyze the following compilation guide statement: #pragma sor_start and #pragma sor_end: used for manually marking the start and end of SoR area in source program; #pragma checkpoint: used for marking checkpoint position; Configure ROSE compiler as auxiliary tool, make it can automatically analyze the semantic logic of source program, recognize the implicit repeatable operation, and automatically insert #pragma sor_start and #pragma sor_end, ensure that SoR area completely covers the logic needing to be synchronized by double thread, and supplement the omissions of manual annotation. Specific embodiment five: The difference between the embodiment five and the embodiment four is only that: Wrap repeatable operation with #pragma sor_start and #pragma sor_end in source program, explicitly include it into SoR area; Insert #pragma checkpoint at key node in SoR area; Non-repeatable operation does not need to be wrapped, and is executed by main thread by default, and does not enter SoR area. Specific embodiment six: The difference between the embodiment six and the embodiment five is only that: Perform syntax analysis on source program, automatically recognize the code segment which is not explicitly annotated but meets the "repeatable operation" characteristics, generate supplementary #pragma sor_start and #pragma sor_end, and ensure that there is no omission in SoR area; Type analysis is performed on variables in the SoR region, key variables to be compared are automatically marked, a #pragma compare_var statement is generated, and manual omission of core variables is avoided. Specific embodiment seven: The difference between the embodiment seven and the embodiment six is only that: Main thread code generation: the source program logic is completely reserved, the thread_sync() function is embedded in the SoR region, and the variable of the repeatable operation is written into the shared buffer in real time during the execution process to ensure that the variable of the repeatable operation is written into the shared buffer in real time during the execution process; checkpoint_trigger() is inserted at the #pragma checkpoint mark, and when executed, the logic of "pause execution -> write the current variable to the buffer -> enter blocked waiting" is triggered; Redundant thread code generation: only the repeatable operation code in the SoR region is extracted, and the sor_mark() function is used to ensure that the repeatable operation of the main thread is completely synchronized; checkpoint_trigger() is also inserted at the #pragma checkpoint mark, and when executed, the logic of "pause execution -> read the main thread variable from the shared buffer -> call result_verify() for comparison" is triggered. Specific embodiment eight: The difference between the embodiment eight and the embodiment seven is only that: Thread starting and initial synchronization: the operating system schedules the main thread and the redundant thread to start on different cores in parallel, and the thread_sync() function is used to complete the initial data synchronization to ensure that the double threads start execution from the same state; Checkpoint triggering and data comparison: when the double threads execute to the #pragma checkpoint mark, the main thread writes the variable value of the current repeatable operation to the shared buffer through checkpoint_trigger(), and then enters the blocked waiting state; The redundant thread is synchronized and paused, the variable value of the main thread is read from the buffer through thread_sync(), result_verify() is called to compare the result of the repeatable operation with itself, if the data volume is reduced, the data is compared bit by bit; if the data volume is increased, the MD5 algorithm is automatically called to generate a hash value, and the original data comparison is replaced by comparing the 128-bit hash value to reduce the amount of calculation. Specific embodiment nine: The difference between the embodiment nine and the embodiment eight is only that: The application provides a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement a multi-thread parallel redundancy fault-tolerant method based on a compilation layer. Embodiment ten: The difference between the embodiment ten and the embodiment nine is only that: The application provides a computer device, including a memory and a processor, the memory stores a computer program, and the processor realizes a multi-thread parallel redundancy fault-tolerant method based on a compilation layer when the computer program is executed. Specific implementation method eleven: The difference between the embodiment eleven and the embodiment ten is only that: Step one: defining thread division and SoR area core definition. First, define the responsibility boundary and operation range of the double thread: Leading thread: as the main entrance of program execution, it needs to cover the business logic completely, both executing repeatable operations (such as sensor data reading, PID control algorithm, etc. idempotent operation, the execution result only depends on the input and has no side effect) and non-repeatable operations (such as hardware initialization, register configuration, random number generation, etc. non-idempotent operation, only needs to be executed once and depends on the hardware state); Trailing thread: as a fault-tolerant check carrier, it only focuses on the synchronization and comparison of core logic, executes the repeatable operation consistent with the leading thread, and executes the result comparison at the key node (compares the repeatable operation results of itself and the leading thread); SoR area (copy area): it specially contains the "repeatable operation" that needs to be synchronized by the double thread, ensures that the redundant thread can accurately copy the core logic of the leading thread, and excludes non-repeatable operations to avoid invalid redundancy.

[0042] Step two: encapsulating the SoR area related fault-tolerant function library. Encapsulate the core fault-tolerant function as a header file (such as mthread.h), and ensure that the library file contains the tool function with strong association with the SoR area: sor_mark(): used to mark the start and end of "repeatable operation" in the compilation stage, define the boundary of SoR area, and support the compiler to identify the instructions and variables that need to be copied; thread_sync(): realizes double thread data synchronization, provides the interface of "repeatable operation variable writing to shared buffer" for the leading thread, and provides the interface of "reading the leading thread variable from the buffer" for the redundant thread; checkpoint_trigger(): checkpoint trigger function, controls the double thread to pause synchronously at the checkpoint position in Fig. 3 , ensures the consistency of comparison opportunity; result_verify(): result comparison function specially for the redundant thread, supports bit-by-bit comparison and Hash value comparison (adapted to large data scenarios) of the original data.

[0043] Step three: compiler and toolchain adaptation Integrate mthread.h into the static library of the compiler (such as GCC, LLVM) that supports embedded multi-core platforms, to ensure that the compiler can recognize and parse the following compilation directives: #pragma sor_start and #pragma sor_end: used to manually mark the start and end of SoR regions in the source program, corresponding to Fig. 1 the dashed box range of SoR regions in the figure; #pragma checkpoint: used to mark checkpoint positions (such as loop entry, function call), corresponding to Fig. 3 the nodes of double-thread synchronization pause in the figure; Configure the ROSE compiler as an auxiliary tool, which can automatically analyze the semantic logic of the source program, identify implicit repeatable operations (such as functions that are not manually marked but meet the idempotency), and automatically insert #pragma sor_start and #pragma sor_end, to ensure that SoR regions completely cover the logic that needs to be synchronized by double threads, and supplement the omissions of user manual annotations.

[0044] Step four: source program annotation and automatic identification. In the source program, wrap the repeatable operations (such as sensor data acquisition functions, PID calculation loops) with #pragma sor_start and #pragma sor_end to explicitly include them in the SoR region; Insert #pragma checkpoint at key nodes within the SoR region (such as every 10 loops), corresponding to Fig. 3 the checkpoints for double-thread synchronization comparison in the figure; Non-repeatable operations (such as the hardware initialization function init_hardware()) do not need to be wrapped, and are executed exclusively by the main thread, not entering the SoR region.

[0045] Step five, ROSE compiler automatic identification and supplementation.

[0046] Perform syntax analysis on the source program, automatically identify code segments that do not explicitly annotate but meet the "repeatable operation" characteristics (such as pure mathematical calculation functions), and generate supplementary #pragma sor_start and #pragma sor_end to ensure that there are no omissions in the SoR region; Perform type analysis on the variables within the SoR region, automatically label the key variables that need to be compared (such as speed_sensor, pid_output), and generate #pragma compare_var statements to avoid user manual omissions of core variables.

[0047] Step six: SoR region compilation and dual-thread code generation.

[0048] Main thread code generation: complete preservation of source program logic, embedding thread_sync() function in SoR region, ensuring real-time writing of repeatable operation variables to shared buffer during execution; Insert checkpoint_trigger() at #pragma checkpoint marker, triggering "pause execution -> write current variables to buffer -> enter blocked waiting" logic upon execution, corresponding to Fig. 3 Consistency of main thread state at checkpoint in Step 5; Redundant thread code generation: only extract repeatable operation code within SoR region, ensure complete synchronization with main thread's repeatable operation (instruction sequence, variable value) through sor_mark() function; Insert checkpoint_trigger() at #pragma checkpoint marker, triggering "pause execution -> read main thread variables from shared buffer -> call result_verify() for comparison" logic upon execution, corresponding to Fig. 3 "Result comparison" action of redundant thread at checkpoint in Step 5.

[0049] Step seven: dual-thread parallel execution and checkpoint interaction.

[0050] Thread startup and initial synchronization: operating system schedules main thread and redundant thread to start parallel on different cores, completes initial data synchronization (such as input parameters, initial variable values) through thread_sync() function, ensuring dual-thread execution from the same state, corresponding to Fig. 3 Fig. 3 Starting alignment of dual threads in Step 5; Checkpoint triggering and data comparison: when dual-thread execution reaches #pragma checkpoint marker, main thread writes current repeatable operation variable values to shared buffer through checkpoint_trigger(), then enters blocked waiting state; Redundant thread synchronization pause, reads main thread variable values from buffer through thread_sync(), calls result_verify() to compare with its own repeatable operation results, if data volume is small (such as single variable value), directly compare bit by bit; if data volume is large, automatically call MD5 algorithm to generate hash value, compare 128-bit hash value instead of original data comparison, reducing computational complexity; Step eight, result processing and flow continuation. If the comparison result is consistent, the redundant thread backs up the current variable value, program counter and other states to an independent backup structure, sends a wake-up signal through thread_sync(), and the main thread receives the signal and continues to execute the subsequent code together with the redundant thread; If the comparison result is inconsistent, it is determined as a transient fault, the redundant thread reads the correct data of the last checkpoint from the backup structure, covers the variable value of the main thread and itself through thread_sync(), resets the program counter to the checkpoint position, sends a wake-up signal, and then the two threads backtrack to the checkpoint to re-execute until the result is consistent.

[0051] The above is only a preferred embodiment of the multi-thread parallel redundancy fault-tolerant method based on the compilation layer, and the protection scope of the multi-thread parallel redundancy fault-tolerant method based on the compilation layer is not limited to the above-mentioned embodiment. Any technical solution under the same idea belongs to the protection scope of the present application. It should be noted that for those skilled in the art, some improvements and changes without departing from the principles of the present application should also be considered as the protection scope of the present application.

Claims

1. A multi-threaded parallel redundant fault-tolerant method based on a compiled layer, characterized by: The method comprises the following steps: Step 1: determine thread division and SoR area core; Step 2: encapsulate SoR area related fault tolerance function library, encapsulate core fault tolerance function as header file, and ensure that the library file contains tool functions with strong association with the SoR area; Step 3: compiler and tool chain adaptation; Step 4: mark and automatically identify the source program; Step 5: automatic identification and supplement of ROSE compiler; Step 6: SoR area compilation and double-thread code generation; Step 7: double-thread parallel execution and checkpoint interaction; Step 8: redundancy fault tolerance processing and flow continuation.

2. The method of claim 1, wherein: the main thread is the main entrance of program execution, completely covers the business logic, and performs both repeatable operations and non-repeatable operations; the redundant thread is a fault tolerance check carrier, focuses on the synchronization and comparison of core logic, performs repeatable operations consistent with the main thread, and performs result comparison at key nodes; the SoR area specifically contains "repeatable operations" that need to be synchronized by double threads, ensures that the redundant thread replicates the core logic of the main thread, and excludes non-repeatable operations to avoid invalid redundancy.

3. The method of claim 2, wherein: sor_mark(): used to mark the start and end of "repeatable operations" in the compilation stage, explicitly mark the boundary of the SoR area, and support the compiler to identify the instructions and variables that need to be copied; thread_sync(): realizes double-thread data synchronization, provides an interface for the main thread to write "repeatable operation variable" to the shared buffer, and provides an interface for the redundant thread to read the main thread variable from the buffer; checkpoint_trigger(): checkpoint trigger function, controls the double threads to pause synchronously at the checkpoint position, and ensures consistent comparison opportunity; result_verify(): result comparison function dedicated to the redundant thread, supports bit-by-bit comparison and Hash value comparison of original data.

4. The method of claim 3, wherein: integrate mthread.h into the compiler static link library supporting embedded multi-core platforms, and ensure that the compiler can recognize and parse the following compilation guide statements: #pragma sor_start and #pragma sor_end: used to manually mark the start and end of the SoR area in the source program; #pragma checkpoint: used to mark the checkpoint position; configure the ROSE compiler as an auxiliary tool, so that it can automatically analyze the semantic logic of the source program, identify implicit repeatable operations, and automatically insert #pragma sor_start and #pragma sor_end, to ensure that the SoR area completely covers the logic that needs to be synchronized by double threads, and supplements the omissions of user manual annotation.

5. The method of claim 4, wherein: in the source program, wrap the repeatable operations with #pragma sor_start and #pragma sor_end to explicitly include the SoR area. #pragma checkpoint is inserted at the key node within the SoR region; Non-idempotent operations do not need to be wrapped, and are executed exclusively by the main thread without entering the SoR region.

6. The method of claim 5, wherein: The source program is parsed to automatically identify code segments that meet the "idempotent" characteristics but are not explicitly labeled, and supplemental #pragma sor_start and #pragma sor_end are generated to ensure that the SoR region is not missed. Type analysis is performed on the variables within the SoR region to automatically label key variables that need to be compared, and #pragma compare_var statements are generated to avoid user manual omission of core variables.

7. The method of claim 6, wherein: Main thread code generation: The source program logic is completely preserved, and the thread_sync() function is embedded within the SoR region to ensure that idempotent variables are written to the shared buffer in real time during execution; checkpoint_trigger() is inserted at the #pragma checkpoint label, which triggers the logic of "pause execution → write current variables to the buffer → enter blocked waiting" when executed; Redundant thread code generation: Only the idempotent code within the SoR region is extracted, and the sor_mark() function is used to ensure complete synchronization with the idempotent operations of the main thread; checkpoint_trigger() is also inserted at the #pragma checkpoint label, which triggers the logic of "pause execution → read the main thread variables from the shared buffer → call result_verify() for comparison" when executed.

8. The method of claim 7, wherein: Thread startup and initial synchronization: The operating system schedules the main thread and the redundant thread to start on different cores in parallel, and the thread_sync() function is used to complete the initial data synchronization to ensure that the two threads start execution from the same state; Checkpoint triggering and data comparison: When the two threads execute to the #pragma checkpoint label, the main thread writes the current idempotent variable values to the shared buffer through checkpoint_trigger(), and then enters the blocked waiting state; The redundant thread is synchronized and paused, reads the main thread variable values from the buffer through thread_sync(), and calls result_verify() to compare the idempotent operation results with itself. If the data volume is reduced, it is directly compared bit by bit; if the data volume is increased, the MD5 algorithm is automatically called to generate a hash value, and the 128-bit hash value is compared instead of the original data comparison to reduce the amount of calculation.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The program is executed by a processor for implementing the method of any one of claims 1-8.

10. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that: The processor executes the computer program to implement the method of any one of claims 1-8.

Images