WCET analysis method and device for embedded multi-thread program

Abstract

The invention relates to the field of embedded technologies, in particular to a WCET analysis method and device for an embedded multi-thread program. The method comprises the steps that synchronous operation in a multi-thread program under the POSIX thread standard is recognized, lock-related operation statements are recorded, and an expanded parallel program control flow diagram is generated to describe the synchronous dependency relationship between threads; based on a lock-protected critical region resource mutual exclusion access principle, calculating a program WCST caused by critical resource application of a thread; according to a control flow diagram of a parallel program, determining a parallel segment, running on other cores, of a certain program segment, taking the parallel segment as an interference set, and performing conflict analysis on the shared instruction cache through an abstract interpretation method; and inputting the analysis result as a parameter into a WCET calculation method IPET to obtain a WCET analysis result of the whole parallel program.

Description

Technical Field

[0001] The present application relates to the field of embedded technology, and in particular to a WCET analysis method and device for embedded multi-threaded programs. Background Art

[0002] In real-time systems, the worst-case execution time (WCET) is an important performance evaluation metric that provides the basis for ensuring that tasks are reliably executed within a predetermined strict time limit. The WCET estimate must have two properties:

[0003] (1) Safety: This means that it should be greater than or equal to any possible execution time;

[0004] (2) Strictness: that is, as close to the actual worst-case execution time as possible.

[0005] In order to improve the accuracy of WCET analysis, the task behavior under specific hardware architectures must be considered. In these architectures, the cache has a large impact on program execution time. The prediction of cache hits and misses may cause the instruction execution time to differ by nearly one hundred clock cycles. Therefore, the accuracy of cache analysis is crucial to the estimation of task execution time.

[0006] Due to their high processing efficiency, multi-core processors are becoming more and more common in real-time operating systems. Although multi-core processors improve performance by allowing multiple tasks to run simultaneously on different cores, they cannot shorten the execution time of a single task and therefore cannot help meet the deadline requirements of real-time applications. In order to shorten the running time, an effective method is to parallelize the application code, but this will also introduce complex synchronization relationships between threads. In existing methods of WCET analysis of multi-core platforms, tasks executed on different cores are often considered independent, and the impact of inter-thread synchronization on the WCET of multi-threaded programs is not considered, which limits the analysis scenarios of tasks.

[0007] At the same time, in multi-core processors, the last-level cache is usually shared by all processing cores, which means that the content of the shared cache depends not only on the task executed on a single core, but also on other tasks executed in parallel.

[0008] In addition, multi-threaded programs usually involve synchronization mechanisms, and the complex partial order relationship between threads makes it more difficult to determine which instructions of different cores will compete for the same cache set. Existing methods usually assume that each instruction in the analyzed thread may compete for shared resources with the entire thread area in the competing thread, which will cause the WCET analysis results to be overly pessimistic. Summary of the invention

[0009] In order to solve the above problems, the present application provides a WCET analysis method and device for embedded multi-threaded programs.

[0010] The embodiment of the present application is implemented as follows:

[0011] In a first aspect, the present application provides a WCET analysis method for an embedded multi-threaded program, comprising:

[0012] Identify synchronization operations in multi-threaded programs under the POSIX thread standard, record lock-related operation statements, and generate an extended parallel program control flow graph to describe the synchronization dependencies between threads;

[0013] Based on the principle of mutually exclusive access to critical section resources protected by locks, the worst-case waiting time (WCST) of the program caused by the application of critical resources by the thread is calculated;

[0014] According to the control flow graph of the parallel program, the parallel segments of a certain program segment running on other cores are determined, and used as interference sets to perform conflict analysis on the shared instruction cache through an abstract interpretation method;

[0015] The above analysis results are input as parameters into the WCET calculation method IPET to obtain the WCET analysis results of the entire parallel program.

[0016] In a possible implementation, identifying synchronization operations in a multi-threaded program under the POSIX thread standard, recording lock-related operation statements, and generating an extended parallel program control flow graph to describe synchronization dependencies between threads further includes:

[0017] According to the multi-threaded program based on the POSIX thread standard given by the user, thread-related operations are identified through traversal, including thread control (thread creation, thread merging) and thread synchronization (locking);

[0018] According to the above information, corresponding additional information is added to the control flow graph of the multi-threaded program.

[0019] In a possible implementation, the identification of synchronization operations in a multi-threaded program under the POSIX thread standard, recording lock-related operation statements, and generating an extended parallel program control flow graph to describe synchronization dependencies between threads also includes:

[0020] The expanded control flow graph can clearly express the synchronization dependencies between threads.

[0021] In a possible implementation, the step of analyzing the worst-case waiting time of the program further includes:

[0022] Determine the worst-case wait time scenario: when a thread attempts to acquire a lock, all other threads simultaneously apply for the lock to compete with it;

[0023] For each lock, list the set of threads that may have contention, calculate the worst-case execution time of the basic block where the critical section resources are located, and simulate the worst-case waiting time of the program caused by critical section mutual exclusion in the above worst-case scenario, and record it as WCST.

[0024] In a possible implementation, the determining of the parallel segments of a certain program segment running on other cores and using them as interference sets, and performing conflict analysis on the shared instruction cache by an abstract interpretation method further includes:

[0025] Based on the traditional abstract interpretation method and fixed point analysis, the analysis results of the first-level cache and the second-level cache of the task executed on a single core are obtained, and the cache state and cache access state are abstracted in the process;

[0026] Shared cache conflicts may occur between programs executed in parallel. Therefore, based on the control flow graph of the parallel program, the possible parallel segments on other cores are divided for each program segment as the interference set.

[0027] For each program segment, a shared instruction cache conflict analysis is performed based on the above interference set partitioning information.

[0028] In a possible implementation, the cache status is abstracted into four categories: Always Hit (AH), Always Miss (AM), First Miss (FM), and Not Classified (NC);

[0029] The cache access status is abstracted into three categories: Always (A), Never (N) and Uncertain (U).

[0030] In a possible implementation, the shared instruction cache conflict analysis further includes:

[0031] Determine the hit status of the interference concentrated instructions on the shared cache and the cache line mapping status in the hit state;

[0032] The single instruction shared cache hit status is updated according to the analysis results, thereby obtaining the shared instruction cache conflict information of the entire parallel program.

[0033] In a possible implementation, the step of inputting the above analysis result as a parameter into the WCET calculation method IPET to obtain the WCET analysis result of the entire parallel program further includes:

[0034] The IPET method is implicit path enumeration. During the algorithm, it is necessary to determine the WCET estimate of each instruction and the maximum number of executions of each instruction.

[0035] Then it is modeled as an integer linear programming problem and solved. By modeling the cache architecture, the execution time required for each instruction can be calculated when the cache exists.

[0036] The number of execution times of instructions in a basic block can be obtained based on the control flow graph.

[0037] In a possible implementation, the step of obtaining the number of executions of instructions in the basic block according to the control flow graph further includes:

[0038] The WCST analysis results need to be integrated into the IPET analysis framework. The integration process includes adding corresponding constraints, modifying the basic block execution time, etc.

[0039] In a second aspect, the present application provides a WCET analysis device for an embedded multi-threaded program, comprising:

[0040] An identification module is used to identify synchronization operations in multi-threaded programs under the POSIX thread standard, record lock-related operation statements, and generate an extended parallel program control flow graph to describe synchronization dependencies between threads;

[0041] The simulation module is used to calculate the worst-case waiting time (WCST) of the program caused by the thread applying for critical resources based on the principle of mutually exclusive access to critical section resources protected by locks;

[0042] The analysis module is used to determine the parallel segments of a program segment running on other cores according to the control flow graph of the parallel program, and use this as the interference set to perform conflict analysis on the shared instruction cache through an abstract interpretation method;

[0043] The calculation module is used to input the above analysis results as parameters into the WCET calculation method IPET to obtain the WCET analysis results of the entire parallel program.

[0044] The technical solution provided by this application can at least achieve the following beneficial effects:

[0045] The WCET analysis method for embedded multi-threaded programs provided in this application consists of two parts, including the worst-case execution time of ordinary code and the worst-case waiting time due to thread synchronization. In the framework, the control flow graph of the multi-threaded program is first constructed, and the WCST can be obtained according to the mutual exclusion relationship analysis of the critical section. In the time analysis, the impact of shared instruction cache conflicts needs to be considered. A new shared instruction cache interference set partitioning algorithm is proposed to achieve accurate analysis of shared cache conflicts. Finally, the WCET of the entire multi-threaded program is automatically obtained through the IPET method. Experimental results prove the feasibility of the framework and improve the analysis accuracy of the shared instruction cache. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0047] Figure 1 It is a flowchart of a WCET analysis method for an embedded multi-threaded program shown in an exemplary embodiment of the present application;

[0048] Figure 2 is a schematic diagram of a tool framework for performing WCET analysis shown in an exemplary embodiment of the present application;

[0049] Figure 3 is a schematic diagram of a program control flow graph representation shown in an exemplary embodiment of the present application;

[0050] Figure 4 is a schematic diagram of lock contention in the worst case shown in an exemplary embodiment of the present application;

[0051] Figure 5 It is a structural diagram of a WCET analysis device for embedded multi-threaded programs shown in an exemplary embodiment of the present application.

[0052] Reference numerals:

[0053] 1. Identification module; 2. Simulation module; 3. Analysis module; 4. Calculation module. DETAILED DESCRIPTION

[0054] In order to make the purpose, implementation mode and advantages of the present application clearer, the exemplary implementation mode of the present application will be clearly and completely described below in conjunction with the drawings in the exemplary embodiments of the present application. Obviously, the described exemplary embodiments are only part of the embodiments of the present application, not all of the embodiments. It should be understood that the specific embodiments described here are only used to explain the present application and are not used to limit the present application.

[0055] It should be noted that the brief description of terms in this application is only for the convenience of understanding the embodiments described below, and is not intended to limit the embodiments of this application. Unless otherwise specified, these terms should be understood according to their common and usual meanings.

[0056] The terms "first", "second", "third", etc. in the specification and claims of this application and the above drawings are used to distinguish similar or similar objects or entities, and do not necessarily mean to limit a specific order or sequence, unless otherwise noted. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances.

[0057] The terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device comprising a list of components is not necessarily limited to all the components expressly listed but may include other components not expressly listed or inherent to such product or device.

[0058] Before explaining the WCET analysis method for embedded multi-threaded programs provided in the embodiment of the present application, the application scenario and implementation environment of the embodiment of the present application are first introduced.

[0059] In real-time systems, the worst-case execution time (WCET) is an important performance evaluation metric that provides the basis for ensuring that tasks can be reliably executed within a predetermined strict time limit. The WCET estimate must have two properties: (1) safety, which means that it should be greater than or equal to any possible execution time, and (2) strictness, which means that it should be as close to the actual worst-case execution time as possible. In order to improve the accuracy of WCET analysis, the task behavior under specific hardware architectures must be considered. In these architectures, the cache has a large impact on program execution time, and the prediction of cache hits and misses may result in instruction execution times that differ by nearly a hundred clock cycles. Therefore, the accuracy of cache analysis is crucial to task execution time estimation.

[0060] Multi-core processors are becoming more and more common in real-time operating systems due to their high processing efficiency. Although multi-core processors improve performance by allowing multiple tasks to run simultaneously on different cores, they cannot shorten the execution time of a single task and therefore cannot help meet the deadline requirements of real-time applications. In order to shorten the running time, an effective method is to parallelize the application code, but this also introduces complex synchronization relationships between threads. In existing methods for WCET analysis of multi-core platforms, tasks executed on different cores are often considered independent, without considering the impact of inter-thread synchronization on the WCET of multi-threaded programs, which limits the analysis scenarios of tasks.

[0061] At the same time, in multi-core processors, the last-level cache is usually shared by all processing cores, which means that the content of the shared cache depends not only on the tasks executed on a single core, but also on other tasks executed in parallel. In addition, multi-threaded programs usually involve synchronization mechanisms, and the complex partial order relationship between threads makes it more difficult to determine which instructions of different cores will compete for the same cache set. Existing methods usually assume that each instruction in the analyzed thread may compete for shared resources with the entire thread area in the competing thread, which will make the WCET analysis results too pessimistic.

[0062] Based on this, the present application provides a WCET analysis method and device for embedded multi-threaded programs, introduces a new interference set partitioning algorithm for shared instruction cache conflict analysis, firstly identifies thread operation primitives to obtain an extended control flow graph of the parallel program, which describes relevant information such as synchronization between threads; then analyzes the worst execution situation of the program with critical sections, that is, when a thread tries to acquire a lock, all other threads compete with it at the same time, thereby determining the worst-case waiting time (WCST) of the program; in terms of cache analysis, introduces a new shared instruction cache interference set partitioning algorithm, determines the parallel segment of the program segment according to the synchronization information in the program, and uses this as the cache interference set, and timely updates the hit situation of each instruction for the shared cache through a custom conflict definition strategy; finally, integrates the above analysis results into the IPET WCET calculation framework to obtain the WCET of the entire multi-threaded program.

[0063] Next, the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems will be described in detail through embodiments and in combination with the accompanying drawings. The embodiments may be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. Obviously, the described embodiments are part of the embodiments of the present application, not all of them.

[0064] Figure 1 is a flowchart of a WCET analysis method for an embedded multi-threaded program shown in an exemplary embodiment of the present application. Figure 2 It is a schematic diagram of a tool framework for performing WCET analysis shown in an exemplary embodiment of the present application.

[0065] In an exemplary embodiment, Figure 1 As shown, a WCET analysis method for an embedded multi-threaded program is provided. In this embodiment, the method may include the following steps:

[0066] Step 100: Identify synchronization operations in a multi-threaded program under the POSIX thread standard, record lock-related operation statements, and generate an extended parallel program control flow graph to describe synchronization dependencies between threads.

[0067] Step 200: Based on the principle of mutually exclusive access to critical section resources protected by locks, the worst case waiting time (WCST) of the program caused by the thread applying for critical resources is calculated.

[0068] Step 300: According to the control flow graph of the parallel program, determine the parallel segments of a certain program segment running on other cores, and use them as interference sets to perform conflict analysis on the shared instruction cache through an abstract interpretation method.

[0069] Step 400: Input the above analysis results as parameters into the WCET calculation method IPET to obtain the WCET analysis results of the entire parallel program.

[0070] like Figure 2 As shown, specifically including:

[0071] Based on the multi-threaded program given by the user based on the POSIX thread standard, the tool first identifies thread-related operations by traversing, including thread control (thread creation, thread merging) and thread synchronization (locking). Based on the above information, the corresponding additional representation is added to the control flow graph of the multi-threaded program. The expanded control flow graph can clearly express the synchronization dependency between threads.

[0072] First, we need to determine the worst-case waiting time scenario: when a thread tries to acquire a lock, all other threads simultaneously apply for the lock to compete with it. After determining the specific scenario, this tool counts the set of threads that may have a competing relationship for each lock, and then calculates the worst-case execution time of the basic block where the critical section resource is located. By simulating the above worst-case scenario, we can obtain the worst-case waiting time of the program caused by the mutual exclusion of the critical section, which is recorded as WCST.

[0073] Based on the traditional abstract interpretation method and fixed point analysis, the analysis results of the first-level cache and the second-level cache of the task executed on a single core are obtained. In this process, the cache status is abstracted into four categories: Always Hit (AH), Always Miss (AM), First Miss (FM) and Not Classified (NC), and the cache access status is abstracted into three categories: Always (A), Never (N) and Uncertain (U). According to the necessary conditions for cache conflicts to occur: shared cache conflicts can only occur between program segments executed in parallel, so it is necessary to divide each program segment into its possible parallel segments on other cores as interference sets.

[0074] For each program segment, a shared instruction cache conflict analysis is performed based on the above interference set partitioning information. The analysis process includes determining the hit status of the instructions in the interference set for the shared cache and the cache line mapping status in the hit state, and updating the single instruction shared cache hit status based on the analysis results.

[0075] The above analysis results are integrated with the WCET calculation method IPET. The IPET algorithm requires the execution time and execution count of each instruction as input. Through cache analysis, the execution time of each instruction in the presence of cache can be obtained, and the number of instruction executions is counted in basic blocks. Finally, WCST is integrated into the analysis framework by writing constraints to obtain the WCET of the multi-threaded program.

[0076] Figure 3 is a schematic diagram of a program control flow graph representation shown in an exemplary embodiment of the present application, Figure 4 FIG. 4 is a schematic diagram of lock contention in the worst case shown in an exemplary embodiment of the present application.

[0077] In a possible implementation, the specific implementation process of the WCET analysis method is as follows:

[0078] Generate a control flow graph for a multithreaded program:

[0079] A typical control flow graph is a directed acyclic graph, which is composed of basic blocks and edges. It is a basic control structure that describes a program. Figure 1 It is generally used to represent single-core programs. When describing multi-threaded programs, the control flow graph needs to be expanded to represent the execution order, conditional branches, and concurrent execution relationships between tasks or subtasks.

[0080] Some embodiments of the present application scan a multi-threaded program given by a user to identify thread-related operations therein, including thread control (creation, merging) and thread synchronization (mutual exclusion locks). The information is mapped to the relevant nodes of the control flow graph, and additional information is annotated in the basic block to indicate the synchronization dependency between threads. The control flow graph is used as a basis to facilitate subsequent multi-threaded program analysis. The specific control flow graph is as follows: Figure 3 shown.

[0081] Perform WCST analysis to obtain the worst-case waiting time of the program due to mutual exclusion waiting:

[0082] Determine the worst-case waiting time scenario: When a thread tries to acquire a lock, all other threads simultaneously apply for the lock to compete with it, as shown in the diagram below Figure 4 shown.

[0083] For each lock, list the set of threads that may have contention, calculate the worst-case execution time of the basic block where the critical section resources are located, and simulate the worst-case waiting time of the program caused by critical section mutual exclusion in the above worst-case scenario, and record it as WCST.

[0084] The cache modeling process includes single-core task level 1 and level 2 cache analysis and shared instruction cache conflict analysis based on the interference set partitioning algorithm:

[0085] In multi-level cache analysis, the prediction of L-level cache state requires L-1 level cache information. To perform shared cache analysis, we first need to perform Cache Hit Miss Classification (CHMC) on the first-level cache, and obtain the Abstract Cache State (ACS) of each program point in the task through abstract interpretation technology. The program point abstract cache state is divided into four categories, as shown in Table 1:

[0086]

[0087] Table 1 Abstract cache status and description

[0088] At the same time, Cache Access Classification (CAC) is required to determine whether a memory block access occurs at a certain cache level. Its definition is shown in Table 2:

[0089] Cache access status describe Always(A) This level of cache is always accessed Never(N) The cache at this level will not be accessed Uncertain(U) Unable to determine whether the cache level will be accessed

[0090] Table 2 Cache access status and description

[0091] The two will be used as common indicators to determine whether the cache hits.

[0092] For each program segment in a thread, determine its possible parallel segments on other cores.

[0093] Interference set partitioning algorithm:

[0094] Divide the program executed on a single core into three parts: before the critical section, inside the critical section, and after the critical section;

[0095] The correspondence between a certain program segment and a parallel segment is stored in a mapping table structure;

[0096] For each instruction in a program segment, take the set of all instructions in its parallel segment as its interference set.

[0097] Shared instruction cache conflict analysis

[0098] First, we need to clarify the conflict judgment conditions:

[0099] The memory access of the analyzed instruction is in the AH or FM state in the L2 cache and is mapped to a cache line. Assume that the cache line number is n.

[0100] There are also instructions in its interference set, which may access the L2 cache and be mapped to the same cache line n;

[0101] The two access memory concurrently.

[0102] After this analysis process, we can obtain the hit status of the instruction in the first-level cache and the second-level cache, and then determine its total execution time for subsequent WCET calculation.

[0103] WCET calculation based on IPET method:

[0104] The IPET method models the WCET calculation as an integer linear programming problem, which is formulated as follows:

[0105]

[0106] Among them, n represents the number of all instructions, ci represents the WCET of the ith instruction, and xi represents the number of times the ith instruction is executed. Through the above analysis, including control flow analysis and modeling of cache architecture, we have preliminarily obtained the WCET of ordinary programs. By integrating WCST into IPET calculation, we can get the WCET of parallel programs. This can be done by simply writing constraints and putting them into linear solution equations.

[0107] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the instructions, these steps are not necessarily executed in sequence according to the order of the instructions. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the above-mentioned embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0108] Corresponding to the aforementioned embodiment of the WCET analysis method for embedded multi-threaded programs, the present application also provides an embodiment of a WCET analysis device for embedded multi-threaded programs using the same technical concept.

[0109] Figure 5 It is a structural diagram of a WCET analysis device for embedded multi-threaded programs shown in an exemplary embodiment of the present application.

[0110] In an exemplary embodiment, Figure 5 As shown, the WCET analysis device for embedded multi-threaded programs includes:

[0111] Identification module 1, used for identifying synchronization operations in multi-threaded programs under the POSIX thread standard, recording lock-related operation statements, and generating an extended parallel program control flow graph to describe synchronization dependencies between threads;

[0112] Simulation module 2 is used to calculate the worst case waiting time (WCST) of the program caused by the thread applying for critical resources based on the principle of mutual exclusive access to critical section resources protected by locks;

[0113] Analysis module 3, used for determining the parallel segments of a certain program segment running on other cores according to the control flow graph of the parallel program, and using this as an interference set to perform conflict analysis on the shared instruction cache through an abstract interpretation method;

[0114] The calculation module 4 is used to input the above analysis results as parameters into the WCET calculation method IPET to obtain the WCET analysis results of the entire parallel program.

[0115] It can be seen that:

[0116] Existing real-time systems usually face strict execution deadlines, and the worst-case execution time (WCET), as a key performance indicator, is usually used for timing verification. With the development of multi-core processors, parallel programming, as a common method to improve system performance, has also brought new challenges to WCET analysis. Previous studies usually assume that tasks are independent, thereby ignoring the impact of thread synchronization on the WCET of parallel applications. At the same time, existing methods believe that all memory accesses to the same cache set by different cores will cause cache conflicts, resulting in overly pessimistic timing estimates.

[0117] The present invention provides a WCET analysis method and device for embedded multi-threaded programs, and introduces a shared instruction cache conflict analysis based on an interference set partitioning algorithm. This set of theories can be easily integrated with a typical static analysis framework, and experimental results prove the correctness of the framework, and effectively improve the performance of cache analysis.

[0118] For the specific definition of the WCET analysis device for embedded multi-threaded programs, please refer to the definition of the WCET analysis method for embedded multi-threaded programs in the above text, which will not be repeated here. Each module in the above-mentioned WCET analysis device for embedded multi-threaded programs can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0119] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0120] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A WCET analysis method for embedded multi-threaded programs, characterized in that: include: Identify synchronization operations in multi-threaded programs under the POSIX thread standard, record lock-related operation statements, and generate an extended parallel program control flow graph to describe the synchronization dependencies between threads; Based on the principle of mutually exclusive access to critical section resources protected by locks, the worst-case waiting time (WCST) of the program caused by the application of critical resources by the thread is calculated; According to the control flow graph of the parallel program, the parallel segments of a certain program segment running on other cores are determined, and used as interference sets to perform conflict analysis on the shared instruction cache through an abstract interpretation method; The above analysis results are input as parameters into the worst case execution time (WCET) calculation method IPET to obtain the WCET analysis results of the entire parallel program.

2. The WCET analysis method for embedded multi-threaded programs according to claim 1, characterized in that: The identifying synchronization operations in a multi-threaded program under the POSIX thread standard, recording lock-related operation statements, and generating an extended parallel program control flow graph to describe synchronization dependencies between threads further includes: According to the multi-threaded program based on the POSIX thread standard given by the user, thread-related operations are identified through traversal, including thread control (thread creation, thread merging) and thread synchronization (locking); According to the above information, corresponding additional information is added to the control flow graph of the multi-threaded program.

3. The WCET analysis method for embedded multi-threaded programs according to claim 2, characterized in that: The method further includes identifying synchronization operations in a multi-threaded program under the POSIX thread standard, recording lock-related operation statements, and generating an extended parallel program control flow graph to describe synchronization dependencies between threads. The expanded control flow graph can clearly express the synchronization dependencies between threads.

4. The WCET analysis method for embedded multi-threaded programs according to claim 1, characterized in that: The worst-case waiting time analysis step of the program further comprises: Determine the worst-case wait time scenario: when a thread attempts to acquire a lock, all other threads simultaneously apply for the lock to compete with it; For each lock, list the set of threads that may have contention, calculate the worst-case execution time of the basic block where the critical section resources are located, and simulate the worst-case waiting time of the program caused by critical section mutual exclusion in the above worst-case scenario, and record it as WCST.

5. The WCET analysis method for embedded multi-threaded programs according to claim 1, characterized in that: The determining of the parallel segments of a certain program segment running on other cores and using them as interference sets, and performing conflict analysis on the shared instruction cache by an abstract interpretation method further includes: Based on the traditional abstract interpretation method and fixed point analysis, the analysis results of the first-level cache and the second-level cache of the task executed on a single core are obtained. In this process, the cache state and cache access state are abstracted; Shared cache conflicts may occur between programs executed in parallel. Therefore, based on the control flow graph of the parallel program, the possible parallel segments on other cores are divided for each program segment as the interference set. For each program segment, a shared instruction cache conflict analysis is performed based on the above interference set partitioning information.

6. The WCET analysis method for embedded multi-threaded programs according to claim 5, characterized in that: The cache status is abstracted into four categories: Always Hit (AH), Always Miss (AM), First Miss (FM) and Not Classified (NC); The cache access status is abstracted into three categories: Always (A), Never (N) and Uncertain (U).

7. The WCET analysis method for embedded multi-threaded programs according to claim 5, characterized in that: The shared instruction cache conflict analysis further comprises: Determine the hit status of the interference concentrated instructions on the shared cache and the cache line mapping status in the hit state; The single instruction shared cache hit status is updated according to the analysis results, thereby obtaining the shared instruction cache conflict information of the entire parallel program.

8. The WCET analysis method for embedded multi-threaded programs according to claim 1, characterized in that: The step of inputting the above analysis results as parameters into the WCET calculation method IPET to obtain the WCET analysis results of the entire parallel program further includes: The IPET method is implicit path enumeration. During the algorithm, it is necessary to determine the WCET estimate of each instruction and the maximum number of executions of each instruction. Then it is modeled as an integer linear programming problem and solved. By modeling the cache architecture, the execution time required for each instruction can be calculated when the cache exists. The number of execution times of instructions in a basic block can be obtained based on the control flow graph.

9. The WCET analysis method for embedded multi-threaded programs according to claim 5, characterized in that: The execution times of instructions in the basic block can be obtained according to the control flow graph, and further includes: The WCST analysis results need to be integrated into the IPET analysis framework. The integration process includes adding corresponding constraints, modifying the basic block execution time, etc.

10. A WCET analysis device for embedded multi-threaded programs, characterized in that: include: An identification module is used to identify synchronization operations in multi-threaded programs under the POSIX thread standard, record lock-related operation statements, and generate an extended parallel program control flow graph to describe synchronization dependencies between threads; The simulation module is used to calculate the worst-case waiting time (WCST) of the program caused by the thread applying for critical resources based on the principle of mutually exclusive access to critical section resources protected by locks; The analysis module is used to determine the parallel segments of a program segment running on other cores according to the control flow graph of the parallel program, and use this as the interference set to perform conflict analysis on the shared instruction cache through an abstract interpretation method; The calculation module is used to input the above analysis results as parameters into the WCET calculation method IPET to obtain the WCET analysis results of the entire parallel program.

Images