Resource sharing method based on multi-core mixed criticality

Abstract

The application provides a resource sharing method based on multi-core mixed criticality, which comprises the following steps: defining Mrsp resource sharing protocol rules under a multi-core mixed criticality system; analyzing the blocking characteristics of tasks under the resource sharing protocol scheduling in the multi-core mixed criticality system, and analyzing the blocking time suffered by the tasks according to the blocking characteristics; and analyzing the worst response time of the tasks by using the blocking time, and judging the schedulability of the system. The application sets an upper limit of resources to define the resource sharing protocol rules, reduces the blocking of local high-priority tasks caused by low-priority tasks of global resources shared by local low-priority tasks, and improves the schedulability of the system.

Description

Technical Field

[0001] The present application relates to the field of operating system technology, and in particular to a resource sharing method based on multi-core mixed criticality. Background Art

[0002] With the rapid development of contemporary computer technology, the application of embedded systems has become increasingly widespread. Due to considerations such as space, power, and cost, modern complex embedded systems are increasingly integrating multiple functions onto a shared computing platform. Within such integrated systems, tasks with varying certification requirements (and varying criticality levels) can coexist. For example, the DO-178C standard for avionics certification defines five assurance levels (AEs) based on the criticality of operational failures. This led Vestal et al. to propose the concept of mixed criticality (MC) systems.

[0003] In systems with shared resources, tasks running on a common platform require exclusive access to shared resources (e.g., data structures, I / O, and network ports) to ensure operational integrity. However, resource access contention can lead to priority inversion. When a low-priority task exclusively accesses a shared resource while a high-priority task simultaneously requests access to the same resource, the high-priority task is blocked, meaning it must wait for the low-priority task to complete its use of the resource. This blocking can cause additional delays for the high-priority task, thereby reducing the system's schedulability.

[0004] On uniprocessor systems, there are several widely used resource sharing protocols, such as the Priority Ceiling Protocol (PCP), the Stack Resource Policy (SRP), and the Deadline Floor Protocol (DFP). With the advent of multiprocessor technology, resource sharing issues have become more prominent. Empirical studies have shown that on a system with 16 processors, contention for data structures can increase the execution time of applications by approximately 30% due to busy waiting for shared resources. Currently, there is no optimal resource sharing protocol for multiprocessor systems. However, many solutions have been proposed to manage global shared resources, such as Multiprocessor PCP (MPCP), Multiprocessor SRP (MSRP), and Multiprocessor Resource Sharing Protocol (MrsP).

[0005] The above research is based on a standard processor system without mixed-criticality tasks. While significant prior work has addressed resource contention in standard processor systems, limited work has been done in mixed-criticality systems (MC systems). In MC systems, tasks can suffer not only priority inversion but also criticality inversion. This means that if a low-criticality task is holding and accessing resources when the system switches to a high-criticality level, it cannot be immediately deleted and will block the execution of the high-criticality task. This criticality inversion complicates resource contention and ultimately impacts the schedulability of mixed-criticality systems. Summary of the Invention

[0006] The present application provides a resource sharing method based on multi-core mixed criticality, which can be used to solve the technical problem of poor schedulability of mixed criticality systems.

[0007] The present application provides a resource sharing method based on multi-core mixed criticality, the method comprising:

[0008] Step 1: Specify the rules of the Mrsp resource sharing protocol in a multi-core mixed criticality system;

[0009] Step 2: Analyze the blocking characteristics of tasks in a multi-core mixed-criticality system under resource sharing protocol scheduling, and analyze the blocking time incurred by the tasks based on the blocking characteristics;

[0010] Step 3: Use blocking time to analyze the worst response time of the task and determine the schedulability of the system.

[0011] Optional, MRS resource sharing protocol rules for multi-core mixed-criticality systems, including:

[0012] Rule 1: Assign priority to each resource: Without considering resource sharing, the priority of tasks in each processor is assigned according to a fixed priority. The smaller the task period, the higher the priority. Then, assign a set of highest priorities to each resource R, which is represented by (ceiling1,…ceiling m ) indicates that there are m processors in total, for processor p k , resource R is on processor p k The highest priority on the ceiling k Is the processor p k The maximum priority of all tasks using resource R;

[0013] Rule 2: For target resource R i Any access request will cause the priority of the task to be immediately raised to the resource R i Local cap of ;

[0014] Rule 3: Access to resources is processed in FIFO order;

[0015] Rule 4: The system state is divided into two types: stable criticality mode and criticality mode transition phase. At any moment, the system may be in a state of stable criticality mode or criticality mode transition phase, with criticality l1, l2, etc.; in the criticality mode transition phase, criticality l i Switch to l i+1 ; Initially, the system is in low criticality mode l1;

[0016] Rule 5: Mode conversion phase triggering condition: For a criticality of l i The task τ i , τ i Has a set of inherent worst-case execution times ci(l1),…ci(l i ), ci(l1) represents the task τ i The worst execution time in the stable criticality mode with criticality l1, ci(l i ) represents the task τ i At the criticality of l i Worst execution time in stable criticality mode;

[0017] At the criticality of l k And l k <l i When running in the stable criticality mode, once the task τ i The running time exceeds τ i In l k The worst execution time c under i (l k ) and did not complete τ i The critical area will trigger the mode conversion phase, and the system begins to be in the state of l k To l k+1 The stage of transformation; k To l k+1 The transition phase is defined as the transition from task τ i Execution time exceeds c i (l k ) starts from all critical degrees l k The time interval at which the task exits the critical section being executed and is deleted; after that, the system switches to the criticality l k+1 Execution mode;

[0018] Rule 6: While waiting to gain access to a resource and while actually using a resource, a task remains active and executes at a priority equal to the resource's local upper limit.

[0019] Rule 7: Any waiting access to resource Ri The task τ i Must be able to replace tasks on other processors τ j Complete τ j Visit R i The critical section of the task τ j Holding resources R i But it is preempted; task τ i Outstanding requests in the original FIFO queue must be fulfilled.

[0020] Optionally, in the k-level stable criticality mode, the method for the system to execute the MRSP resource sharing protocol rules in the multi-core mixed criticality system includes:

[0021] 1. Task τ ii Arrives at the assigned processor and waits for execution according to the priority of all tasks in the processor;

[0022] 2. Task τ ii Obtain processor privileges and start execution. When task τ i When executing to the critical section that needs to access resources, increase task τ according to rule 2 i priority and wait for resource application according to rule 3;

[0023] 3. If the task τ i The requested resources are being used by tasks on other processors. j Hold, while τ j is preempted by other tasks on the same processor, then according to Rules 6 and 7, task τ j Can be transferred to task τ i The processor where it is located continues to execute and completes τ j Continue execution after the critical section of τ i .

[0024] 4. The method further includes: if the task τ i The actual running time exceeds τ i The system undergoes a mode transition. During the mode transition phase, the criticality of all resources being accessed is ≤ l k The task completes its critical section and releases the resources it holds and is abandoned. The system then enters l k+1 Level stable criticality mode.

[0025] 5. The system enters l k+1 The execution method of the level-stable criticality mode is the same as the method in which the system executes the MRSP resource sharing protocol rules in a multi-core mixed criticality system, which is the same as that in the level-k stable criticality mode.

[0026] Optionally, analyze the blocking characteristics of tasks in a multi-core mixed-criticality system under resource sharing protocol scheduling, and analyze the blocking time incurred by the tasks based on the blocking characteristics, including:

[0027] Step 2.1: In a multi-core mixed-criticality system with shared resources, the blocking experienced by a task is divided into global blocking and local blocking. For a given multi-core mixed-criticality system, the global blocking is represented by BWi,x and is calculated as:

[0028]

[0029] In formula (1), M represents a total of M processors, and m represents the current task τ i The processor number where the task is located, j represents traversing the other M-1 processors except the current processor m, and Ra is the task τ i The resource accessed in the critical section x, The maximum time for another core Pj, j≠m to access resource Ra is calculated as:

[0030]

[0031] In formula (2), represents the processor numbered j, τ l Indicates the task numbered l. Indicates a task The maximum time to access a resource Ra is calculated as follows:

[0032]

[0033] In formula (3), R a The resource accessed by the task, z l,y For the task τ l The yth critical section, c l,y is the critical region z l,y The maximum time required to access the resource;

[0034] Step 2.2: For a given multi-core mixed-criticality system, the blocking of a task by other tasks on the same processor is called local blocking. Based on the characteristics of the multi-core mixed-criticality system, it can be divided into priority inversion blocking and criticality inversion blocking.

[0035] Priority inversion blocking is recorded as pi blocking; the resulting blocking time is recorded as The calculation formula is:

[0036]

[0037] In formula (4), For the task τ i The processor where thej Represents the task τ j The period, p i Represents the task τ i The period, p j,y For the task τ j The cycle limit of the resource accessed by the yth critical section, z j,y For the task τ j The yth critical section, c j,y is the critical region z j,y Maximum time required to access a resource, BW j,y For the task τ j Global blocking on other cores suffered by the yth critical section;

[0038] Step 2.3: The priority inversion blocking in step 2.2, during the criticality level mode transition, the high-criticality task is blocked because the low-criticality task with criticality l on the same processor does not exit the critical section, which is recorded as ci blocking; the blocking time It is obtained by summing the maximum blocking time of each task or the maximum blocking time caused by each resource:

[0039] The maximum blocking time caused by each task for:

[0040]

[0041] In formula (5), hpL(τ i ) is the task τ i All priorities on the processor are higher than τ i And the criticality is lower than τ i The set of tasks, τ j Each processor The task above, j,y For the task τ j The upper limit of the criticality of the resource accessed by the yth critical section, l i For the task τ i The criticality of

[0042] The maximum blocking time caused by each resource for:

[0043]

[0044] In formula (6), hpL(τ i ) is the task τ i All priorities on the processor are higher than τ i And the criticality is lower than τ i The set of tasks, τ j Each processor The task above, j,y For the task τ j The upper limit of the criticality of the resource accessed by the yth critical section, l i For the task τ i The criticality, r j,y Represents the task τ j The resource accessed in the yth critical section, Ra represents the task τ i The resources accessed by each critical section;

[0045] Step 2.4: The maximum criticality inversion blocking suffered by the task is the minimum of the blocking generated by each task and the blocking generated by each resource, that is,

[0046] Step 2.5: Task τ i The worst case blocking time B suffered i for:

[0047]

[0048] Where B i For the task τ i The worst-case blocking time incurred.

[0049] Optionally, use blocking time to analyze the worst-case response time of tasks and determine the schedulability of the system, including:

[0050] Step 3.1: Perform schedulability analysis by calculating the worst-case response time of tasks in the system. In a system with multiple criticality tasks, the worst-case response time of tasks can be divided into two scenarios: one is the worst-case response time in the stable state of criticality level m; the other is the worst-case response time during the mode transition phase.

[0051] Step 3.2: For tasks τ released and completed at criticality level m i , the worst response time R i (m) is obtained recursively by the following formula:

[0052]

[0053] In formula (8), c i (m) represents the task τ i The worst execution time at criticality m, T j For the task τ j The period, c j (m) is the task τ j The worst execution time at criticality m;

[0054] Step 3.3: For the task τ in the mode switching phase iIt may suffer from both PI blocking and CI blocking during different mode conversion stages, so the worst response time The calculation method is:

[0055]

[0056] In formula (9), is the task τ under the criticality m i The ci blocking suffered, q is each criticality lower than the criticality m, T k The period is lower than the task τ i The cycle of the task with a criticality lower than qτ k The cycle, l k For the task τ k The criticality, c k (q) is the task τ k Worst execution time at criticality q;

[0057] Step 3.4: For task τ in a multi-core mixed criticality system i , if:

[0058] R i (1)≤D i ; (10)

[0059]

[0060] Then the task τ i Dispatchable;

[0061] In formula (10), R i (1) represents the task τ i The worst response time when the criticality is 1, which corresponds to the lowest criticality, D i Represents τ i Deadline;

[0062] In formula (11), L i Represents the task τ i The criticality, For the task τ i The worst response time when the criticality is q, Equation (11) shows that in each criticality transition stage, the task τ i The worst response time is lower than the deadline [Beneficial effect]

[0063] This application sets resource upper limits and specifies resource sharing protocol rules, thereby reducing the blocking of local high-priority tasks by low-priority tasks accessing global resources shared by local low-priority tasks, and improving system schedulability. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Figure 1 A schematic diagram of task resource access in a multi-core mixed criticality system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0066] The following first introduces the embodiments of the present application with reference to the accompanying drawings.

[0067] The present application provides a resource sharing method based on multi-core mixed criticality, the method comprising:

[0068] Step 1: Define the rules of the Mrsp resource sharing protocol in a multi-core mixed-criticality system.

[0069] Specifically, the rules of the Mrsp resource sharing protocol in a multi-core mixed-criticality system include:

[0070] Rule 1: Assign priority to each resource: Without considering resource sharing, the priority of tasks in each processor is assigned according to a fixed priority. The smaller the task period, the higher the priority. Then, assign a set of highest priorities to each resource R, which is represented by (ceiling1,…ceiling m ) indicates that there are m processors in total, for processor p k , resource R is on processor p k The highest priority on the ceiling k Is the processor p k The maximum priority of all tasks using resource R on processor p1; ceiling1 represents the highest priority of resource R on processor p1, m Indicates that resource R is on processor p m Each processor that needs to use the resource R corresponds to a highest priority: for processor p k , resource R is on processor p k The highest priority on the ceiling k ) is the processor p k The maximum priority of all tasks using resource R.

[0071] Rule 2: For target resource R i Any access request will cause the priority of the task to be immediately raised to the resource R i local upper limit; (if the task has not yet obtained the resources, the priority will not be increased).

[0072] Here, the original resource sharing agreement task gets R i Directly increase to the upper limit of all local resources, and improve rule 2 to increase to Ri The upper limit of R is avoided i The task does not access R i And tasks with higher priority are blocked.

[0073] Rule 3: Access to resources is processed in FIFO (First In First Out) order;

[0074] Rule 4: The system state is divided into two types: stable criticality mode and criticality mode transition phase. At any moment, the system may be in a state of stable criticality mode or criticality mode transition phase, with criticality l1, l2, etc.; in the criticality mode transition phase, criticality l i Switch to l i+1 ; Initially, the system is in low criticality mode l1;

[0075] Rule 5: Mode conversion phase triggering condition: For a criticality of l i The task τ i , τ i Has a set of inherent worst case execution timings (WCET) ci(l1),…ci(l i ), ci(l1) represents the task τ i The worst execution time in the stable criticality mode with criticality l1, ci(l i ) represents the task τ i At the criticality of l i Worst execution time in stable criticality mode;

[0076] At the criticality of l k And l k <l i When running in the stable criticality mode, once the task τ i The running time exceeds τ i In l k The worst execution time c under i (l k ) and did not complete τ i The critical area will trigger the mode conversion phase, and the system begins to be in the state of l k To l k+1 The stage of transformation; k To l k+1 The transition phase is defined as the transition from task τ i Execution time exceeds ci(l k ) starts from all critical degrees l k The time interval at which the task exits the critical section being executed and is deleted; after that, the system switches to the criticall k +1 Execution mode;

[0077] Rule 6: While waiting to gain access to a resource and while actually using a resource, a task shall remain active and execute at a priority equal to the resource's local upper limit, i.e., it shall not be preempted by lower-priority tasks.

[0078] Rule 7: Any waiting access to resource R i The task τ i Must be able to replace tasks on other processors τ j Complete τ j Visit R i The critical section of the task τ j Holding resources R i But it is preempted; task τ i Outstanding requests in the original FIFO queue must be fulfilled.

[0079] In the K-level stable criticality mode, the method for the system to implement the MRSP resource sharing protocol rules in the multi-core mixed criticality system includes:

[0080] 1. Mission Arrives at the assigned processor and waits for execution according to the priority of all tasks in the processor;

[0081] 2. Mission Obtain processor privileges and start execution. When task τi reaches the critical section where it needs to access resources, it will increase the task τi according to rule 2. i priority and wait for resource application according to rule 3;

[0082] 3. If the task τ i The requested resources are being used by tasks on other processors. j Hold, while τ j is preempted by other tasks on the same processor (i.e., τ j Although holding resources but not executing), according to rules 6 and 7, task τ j Can be transferred to task τ i The processor where it is located continues to execute and completes τ j Continue execution after the critical section of τ i .

[0083] It should be noted that if the task τ i The actual running time exceeds τ i The system undergoes a mode transition. During the mode transition phase, the criticality of all resources being accessed is ≤ l k The task completes its critical section and releases the resources it holds and is abandoned. The system then enters l k+1Level stable criticality mode.

[0084] It should be noted that the system enters l k+1 The execution method of the level-stable criticality mode is the same as the method in which the system executes the MRSP resource sharing protocol rules in a multi-core mixed criticality system, which is the same as that in the level-k stable criticality mode.

[0085] Step 2: Analyze the blocking characteristics of tasks in a multi-core mixed-criticality system under resource sharing protocol scheduling, and analyze the blocking time incurred by the tasks based on the blocking characteristics.

[0086] Specifically, in step 2.1: In a multi-core mixed-criticality system with shared resources, the blocking suffered by a task is divided into global blocking and local blocking. For a given multi-core mixed-criticality system, the global blocking is represented by BWi,x and is calculated as:

[0087]

[0088] In formula (1), M represents a total of M processors (i.e., cores), and m represents the current task τ i The processor number where the task is located, j represents traversing the other M-1 processors except the current processor m, and Ra is the task τ i The resource accessed in the critical section x, The maximum time for another core Pj, j≠m to access resource Ra (i.e., the maximum time that task τi needs to wait for tasks on all other processor cores to access resource Ra in the worst case) is calculated as:

[0089]

[0090] In formula (2), represents the processor numbered j, τ l Indicates the task numbered l. Indicates a task The maximum time to access a resource Ra is calculated as follows:

[0091]

[0092] In formula (3), R a The resource accessed by the task, z l,y For the task τ l The yth critical section, c l,y is the critical region z l,y The maximum time required to access the resource;

[0093] Step 2.2: For a given multi-core mixed-criticality system, the blocking of a task by other tasks on the same processor is called local blocking. Based on the characteristics of the multi-core mixed-criticality system, it can be divided into priority inversion blocking and criticality inversion blocking.

[0094] Priority inversion blocking, that is, a higher priority task is blocked by a lower priority task that is busy waiting or accessing shared resources on the same core, is recorded as pi blocking; the resulting blocking time is recorded as The calculation formula is:

[0095]

[0096] In formula (4), For the task τ i The processor where the j Represents the task τ j The period, p i Represents the task τ i The period, p j,y For the task τ j The upper limit of the cycle of the resource accessed by the yth critical section (that is, the minimum cycle of all tasks accessing the resource on the processor), z j,y For the task τ j The yth critical section, c j,y is the critical region z j,y Maximum time required to access a resource, BW j,y For the task τ j Global blocking on other cores suffered by the yth critical section;

[0097] Step 2.3: The priority inversion blocking in step 2.2, during the criticality level mode transition, the high-criticality task is blocked because the low-criticality task with criticality l on the same processor does not exit the critical section, which is recorded as ci blocking; the blocking time It is obtained by summing the maximum blocking time of each task or the maximum blocking time caused by each resource:

[0098] The maximum blocking time caused by each task for:

[0099]

[0100] In formula (5), hpL(τ i ) is the task τ i All priorities on the processor are higher than τ i (i.e. the period is less than τ i period) and the criticality is lower than τ i The set of tasks, τ j Each processor The task above, j,y For the task τ j The criticality upper limit of the resource accessed by the yth critical section (i.e., the maximum criticality of all tasks accessing the resource), l i For the task τ i The criticality of

[0101] The maximum blocking time caused by each resource for:

[0102]

[0103] In formula (6), hpL(τ i ) is the task τ i All priorities on the processor are higher than τ i (i.e. the period is less than τ i period) and the criticality is lower than τ i The set of tasks, τ j Each processor The task above, j,y For the task τ j The criticality upper limit of the resource accessed by the yth critical section (i.e., the maximum criticality of all tasks accessing the resource), l i For the task τ i The criticality, r j,y Represents the task τ j The resource accessed in the yth critical section, Ra represents the task τ i The resources accessed by each critical section;

[0104] Step 2.4: The maximum criticality inversion blocking suffered by the task is the minimum of the blocking generated by each task and the blocking generated by each resource, that is,

[0105] Step 2.5: Task τ i The worst case blocking time B suffered i for:

[0106]

[0107] Where B i For the task τ i The worst-case blocking time incurred.

[0108] Step 3: Use blocking time to analyze the worst response time of the task and determine the schedulability of the system.

[0109] Specifically, step 3.1: Perform schedulability analysis by calculating the worst response time of tasks in the system. In a system with multiple criticality tasks, the worst response time of tasks can be divided into two cases: one is the worst response time in the stable state of criticality level m; the other is the worst response time in the mode transition phase, that is, the phase when the transition from criticality level m to criticality level (m+1) is completed;

[0110] Step 3.2: For tasks τ released and completed at criticality level m i , Worst Case Response Time (WCET) R i (m) is obtained recursively by the following formula:

[0111]

[0112] In formula (8), c i (m) represents the task τ i The worst execution time at criticality m, T j For the task τ j The period, c j (m) is the task τ j The worst execution time at criticality m;

[0113] Step 3.3: For the task τ in the mode switching phase i It may suffer from both PI blocking and CI blocking during different mode conversion stages, so the worst response time The calculation method is:

[0114]

[0115]

[0116] In formula (9), is the task τ under the criticality m i The ci blocking suffered, q is each criticality lower than the criticality m, T k The period is lower than the task τ i The cycle of the task with a criticality lower than qτ k The cycle, l k For the task τ k The criticality, c k (q) is the task τ k Worst execution time at criticality q;

[0117] Step 3.4: For task τ in a multi-core mixed criticality system i , if:

[0118] R i (1)≤D i ; (10)

[0119]

[0120] Then the task τ i Dispatchable;

[0121] In formula (10), R i (1) represents the task τ i The worst response time when the criticality is 1, which corresponds to the lowest criticality, D i Represents τ i deadline;

[0122] In formula (11), L i Represents the task τ i The criticality, For the task τ i The worst response time when the criticality is q, Equation (11) shows that in each criticality transition stage, the task τ i The worst response time is lower than the deadline.

[0123] The present application is described below with reference to a specific embodiment:

[0124] like Figure 1 As shown in the figure, P1 and P2 represent two processors numbered 1 and 2 respectively, τ1...τ6 represent tasks numbered 1-6, and task τ i By criticality l i and priority p i Two-tuple (l i , p i ) indicates that the larger the value of pi, the higher the priority. The upward bold arrow in the figure indicates the arrival of a task. A(Ri) indicates that a task initiates a request for resource Ri. R(Ri) indicates that a task completes access to resource Ri and releases it. Different colored areas indicate that the task is in the critical section of accessing the corresponding resource. For tasks assigned to two processors that need to access shared resources, the execution status is shown in the figure. On processor P1, the upper priority limits of resources R1, R2, and R3 are 2, 3, and 3, respectively; on processor P2, the upper priority limits of resources R2 and R3 are 2 and 3, respectively. At time t1, task τ5 arrives and requests resource R2. Although τ4 has a lower priority than τ5, the resource R3 that τ4 accesses has a higher priority than τ5. Therefore, τ5 cannot preempt τ4. At time t2, task τ3 on processor P1 attempts to access task R2, but R2 is currently occupied by task τ5 on processor P2. τ5 is then preempted by task τ6. At this point, according to the protocol proposed in this invention, task P1 can use R2, but must complete τ5's critical section. At time t3, τ5 can continue to execute without accessing resources.

[0125] This application sets resource upper limits and specifies resource sharing protocol rules, thereby reducing the blocking of local high-priority tasks by low-priority tasks accessing global resources shared by local low-priority tasks, and improving system schedulability.

[0126] Those skilled in the art can clearly understand that the technology in the embodiments of the present application can be implemented by means of software plus the necessary general hardware platform. Based on this understanding, the technical solutions in the embodiments of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application or certain parts of the embodiments.

[0127] In this specification, the same or similar parts between the various embodiments can be referred to each other. In particular, for the service construction device and service loading device embodiments, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiment.

[0128] The above-described embodiments of the present application do not constitute a limitation on the scope of protection of the present application.

Claims

1. A resource sharing method based on multi-core mixed criticality, characterized in that: The method comprises: Step 1: Specify the rules of the Mrsp resource sharing protocol in a multi-core mixed criticality system; Step 2: Analyze the blocking characteristics of tasks in a multi-core mixed-criticality system under resource sharing protocol scheduling, and analyze the blocking time incurred by the tasks based on the blocking characteristics; Step 3: Use blocking time to analyze the worst response time of the task and determine the schedulability of the system; The rules of the MRSP resource sharing protocol in a multi-core mixed-criticality system include: Rule 1: Assign priority to each resource: Without considering resource sharing, the priority of tasks in each processor is assigned according to a fixed priority. The smaller the task period, the higher the priority. Then, assign a set of highest priorities to each resource R, which is represented by (ceiling1,…ceiling m ) indicates that there are m processors in total, for processor p k , resource R is on processor p k The highest priority on the ceiling k Is the processor p k The maximum priority of all tasks using resource R; Rule 2: For target resource R i Any access request will cause the priority of the task to be immediately raised to the resource R i Local cap of ; Rule 3: Access to resources is processed in FIFO order; Rule 4: The system state is divided into two types: stable criticality mode and criticality mode transition phase. At any moment, the system may be in a state of stable criticality mode or criticality mode transition phase, with criticality l1, l2, etc.; in the criticality mode transition phase, criticality l i Switch to l i+1 ; Initially, the system is in low criticality mode l1; Rule 5: Mode conversion phase triggering condition: For a criticality of l i The task τ i , τ i Has a set of inherent worst-case execution times ci(l1),…ci(l i ), ci(l1) represents the task τ i The worst execution time in the stable criticality mode with criticality l1, ci(l i ) represents the task τ i At the criticality of l i Worst execution time in stable criticality mode; At the criticality of l k And l k <l i When running in the stable criticality mode, once the task τ i The running time exceeds τ i In l k The worst execution time ci(l k ) and did not complete τ i The critical area will trigger the mode conversion phase, and the system begins to be in the state of l k To l k+1 The stage of transformation; k To l k+1 The transition phase is defined as the transition from task τ i Execution time exceeds ci(l k ) starts from all critical degrees l k The time interval at which the task exits the critical section being executed and is deleted; after that, the system switches to the criticality l k+1 Execution mode; Rule 6: While waiting to gain access to a resource and while actually using a resource, a task remains active and executes at a priority equal to the resource's local upper limit. Rule 7: Any waiting access to resource R i The task τ i Must be able to replace tasks on other processors τ j Complete τ j Visit R i The critical section of the task τ j Holding resources R i But it is preempted; task τ i Outstanding requests in the original FIFO queue must be fulfilled.

2. The method according to claim 1, characterized in that In the K-level stable criticality mode, the method for the system to implement the MRSP resource sharing protocol rules in the multi-core mixed criticality system includes:

1. Mission Arrives at the assigned processor and waits for execution according to the priority of all tasks in the processor; 2. Mission Obtain processor privileges and start execution. When task τ i When executing to the critical section that needs to access resources, increase task τ according to rule 2 i priority and wait for resource application according to rule 3; 3. If the task τ i The requested resources are being used by tasks on other processors. j Hold, while τ j is preempted by other tasks on the same processor, then according to Rules 6 and 7, task τ j Can be transferred to task τ i The processor where it is located continues to execute and completes τ j Continue execution after the critical section of τ i .

3. The method according to claim 2, characterized in that The method further comprises: if the task τ i The actual running time exceeds τ i The system undergoes a mode transition. During the mode transition phase, the criticality of all resources being accessed is ≤ l k The task completes its critical section and releases the resources it holds and is abandoned. The system then enters l k+1 Level stable criticality mode.

4. The method according to claim 3, characterized in that System entry k+1 The execution method of the level-stable criticality mode is the same as the method in which the system executes the MRSP resource sharing protocol rules in a multi-core mixed criticality system, which is the same as that in the level-k stable criticality mode.

5. The method according to claim 1, wherein Analyze the blocking characteristics of tasks in a multi-core mixed-criticality system under resource sharing protocol scheduling, and analyze the blocking time suffered by the tasks based on the blocking characteristics, including: Step 2.1: In a multi-core mixed-criticality system with shared resources, the blocking experienced by a task is divided into global blocking and local blocking. For a given multi-core mixed-criticality system, the global blocking is represented by BWi,x and is calculated as: In formula (1), M represents a total of M processors, and m represents the current task τ i The processor number where the task is located, j represents traversing the other M-1 processors except the current processor m, and Ra is the task τ i The resource accessed in the critical section x, The maximum time for another core Pj, j≠m to access resource Ra is calculated as: In formula (2), represents the processor numbered j, τ l Indicates the task numbered l. Indicates a task The maximum time to access a resource Ra is calculated as follows: In formula (3), R a The resource accessed by the task, z l,y For the task τ l The yth critical section, c l,y is the critical region z l,y The maximum time required to access the resource; Step 2.2: For a given multi-core mixed-criticality system, the blocking of a task by other tasks on the same processor is called local blocking. Based on the characteristics of the multi-core mixed-criticality system, it can be divided into priority inversion blocking and criticality inversion blocking. Priority inversion blocking is recorded as pi blocking; the resulting blocking time is recorded as The calculation formula is: In formula (4), For the task τ i The processor where the j Represents the task τ j The period, p i Represents the task τ i The period, p j,y For the task τ j The cycle limit of the resource accessed by the yth critical section, z j,y For the task τ j The yth critical section, c j,y is the critical region z j,y Maximum time required to access a resource, BW j,y For the task τ j Global blocking on other cores suffered by the yth critical section; Step 2.3: The priority inversion blocking in step 2.2, during the criticality level mode transition, the high-criticality task is blocked because the low-criticality task with criticality l on the same processor does not exit the critical section, which is recorded as ci blocking; the blocking time It is obtained by summing the maximum blocking time of each task or the maximum blocking time caused by each resource: The maximum blocking time caused by each task for: In formula (5), hpL(τ i ) is the task τ i All priorities on the processor are higher than τ i And the criticality is lower than τ i The set of tasks, τ j Each processor The task above, j,y For the task τ j The upper limit of the criticality of the resource accessed by the yth critical section, l i For the task τ i The criticality of The maximum blocking time caused by each resource for: In formula (6), hpL(τ i ) is the task τ i All priorities on the processor are higher than τ i And the criticality is lower than τ i The set of tasks, τ j Each processor The task above, j,y For the task τ j The upper limit of the criticality of the resource accessed by the yth critical section, l i For the task τ i The criticality, r j,y Represents the task τ j The resource accessed in the yth critical section, Ra represents the task τ i The resources accessed by each critical section; Step 2.4: The maximum criticality inversion blocking suffered by the task is the minimum of the blocking generated by each task and the blocking generated by each resource, that is, Step 2.5: Task τ i The worst case blocking time B suffered i for: Where B i For the task τ i The worst-case blocking time incurred.

6. The method according to claim 1, characterized in that Use blocking time to analyze the worst response time of tasks and determine the schedulability of the system, including: Step 3.1: Perform schedulability analysis by calculating the worst-case response time of tasks in the system. In a system with multiple criticality tasks, the worst-case response time of tasks can be divided into two scenarios: one is the worst-case response time in the stable state of criticality level m; the other is the worst-case response time during the mode transition phase. Step 3.2: For tasks τ released and completed at criticality level m i , the worst response time R i (m) is obtained recursively by the following formula: In formula (8), c i (m) represents the task τ i The worst execution time at criticality m, T j For the task τ j The period, c j (m) is the task τ j The worst execution time at criticality m; Step 3.3: For the task τ in the mode switching phase i It may suffer from both PI blocking and CI blocking during different mode conversion stages, so the worst response time The calculation method is: In formula (9), is the task τ under the criticality m i The ci blocking suffered, q is each criticality lower than the criticality m, T k The period is lower than the task τ i The cycle of the task with a criticality lower than qτ k The cycle, l k For the task τ k The criticality, c k (q) is the task τ k Worst execution time at criticality q; Step 3.4: For task τ in a multi-core mixed criticality system i , if: R i (1)≤D i ; (10) Then the task τ i Dispatchable; In formula (10), R i (1) represents the task τ i The worst response time when the criticality is 1, which corresponds to the lowest criticality, D i Represents τ i Deadline; In formula (11), L i Represents the task τ i The criticality, For the task τ i The worst response time when the criticality is q, Equation (11) shows that in each criticality transition stage, the task τ i The worst response time is lower than the deadline.

Images