Table of contents
3.4 Calculation of the worst-case blocking time of the protocol
3.4.1 Blocking time calculation in LO mode:
3.4.2 Calculation of blocking time in HI mode:
3.4.3 Blocking time during mode transition
HLC-PCP: a resource synchronization protocol for provably mixed-criticality scheduling
1. Core idea of the paper
The author proposes a new resource synchronization protocol, HLC-PCP, which can guarantee resource sharing and priority inversion control between tasks with different criticality levels under AMC and proves that HLC-PCP can guarantee high criticality levels. The task meets its deadline in the worst case.
2. Related work (AMC)
For details, please refer to Operating System Paper Introduction (7): Response-Time Analysis for Mixed Criticality Systems——Response Time Analysis of Mixed Criticality Systems_Guan Ergou Hurry up and get to work! Blog-CSDN Blog
3. HLC-PCP protocol
3.1 Protocol Definition
Task definition: a set of tasks τ={τ1...τn}, the accessed resource semaphore is represented by S={S1,...,Sm}, each task is defined by the following eight-tuple <T,D, C (vector), P, p, L, l, σ>, the first four define quadruples for basic tasks; p is the activity priority, which can be dynamically changed at runtime according to PCP; L is the task criticality, l is The dynamic criticality may change dynamically at runtime depending on the HLC, where σ is the semaphore group used by the task.
In addition, during the system switching critical mode, since some LO-crit tasks may continue to be active for a period of time due to resource synchronization, in addition to the LO-crit and HI-crit modes in the AMC, the intermediate mode MCP needs to be considered, that is, from any The time interval from the moment a task exceeds its C(LO) value until all LO-crit tasks are discarded and the system enters HI-crit mode.
Define the priority ceiling of AMC when locked in LO-crit mode as the highest value of the priority of all tasks that require the critical section
Define the ceiling priority of AMC when locked in HI-crit mode, similar, just remove the LO task
Define a dynamic priority ceiling for each critical section, which is the highest priority of active tasks that can lock it (for example, when in LO mode, that is all tasks, when in HI mode, that is HI level tasks)
Define a dynamic system priority upper limit dSPC, which is the maximum dynamic priority upper limit of all semaphores currently held by active tasks (note that it is an active task, not all tasks). To put it bluntly, it is all the dynamic priorities of the critical sections that are being occupied. ceiling maximum.
Each semaphore is associated with a constant criticality ceiling, equal to the highest criticality of all tasks that may lock it, which can be understood as a criticality ceiling.
3.2 Agreement workflow
The job scheduling rules applied by HLC-PCP to AMC are as follows:
1. There is a system-wide criticality level indicator θ, initialized to LO. At any time, the system can be in one of three modes: LO-crit mode (θ=LO); HI-crit mode (θ=HI); Mode Change Period (θ=MCP). During system execution, when the task does not hold any semaphore, p=P, l=L (for this task).
2.While(θ=LO), at each moment, the task with the highest priority is selected to be executed.
3. If the currently executing job does not send a completion signal before C (LO), the system enters the mode change cycle. If some LO tasks are executed in the critical section, and this critical section is shared with the HI task, then These tasks are discarded when exiting their critical section; the system enters HI-crit mode when there are no more active LO-crit tasks.
4. Once (θ=HI or MCP), jobs with LO activity criticality are immediately discarded (Note: l=LO is given here, not L). At each moment, the waiting job generated by the HI activity critical task with the highest priority is selected for execution (l=HI is also given here, not L).
5. The activity criticality (l) of task i depends on max(li, CC(Sk)). When the task enters the critical section, the activity criticality may change with the criticality ceiling; after release, it returns to the original criticality before locking. value.
6. To enter the critical section protected by semaphore Sk, the priority of task i must be higher than dPC (S*) (in fact, the priority of the current task, including the highest ceiling priority, of course does not include the critical section protected by Sk ). Furthermore, if a lower-priority task i holds a semaphore Sk and blocks a higher-priority task j trying to lock, then i inherits j's activity priority, that is, pi <-pj. (But in fact, according to the previous statement, Pj=pj at this time is actually a normal priority inheritance protocol).
Here is my personal understanding of defining activity criticality l:
In fact, this effect is mainly reflected in the MCP stage, that is, there are tasks whose duration exceeds C (LO). Use this variable to determine whether some low-criticality tasks are critical. Within the area, and there may be highly critical tasks entering this critical area, the execution of these tasks will not stop immediately, but will be completed until there are no more tasks, and it will enter the HI mode.
Theorem 1: HLC-PCP ensures that any semaphore-protected critical portion required by a HI-crit task will always complete rather than abort.
There is no proof in the article, but it is actually relatively easy to understand.
Since MSP will not deprive the execution of LO tasks that are being executed and whose dynamic criticality l=HI, as long as the LO/HI task enters the shared resource required by the HI task, it will definitely be executed instead of being terminated.
3.3 Agreement example
Supplement: The larger the number, the greater the priority; the time for τ2 to obtain S1 is 10; the maximum total time length of the nested critical section of τ3 is 25; the maximum time for τ4 to obtain S2 is 10.
T0: Task 4 is released and starts running. Since no semaphore is locked, the system priority upper limit dSPC=0; dPC(S1)=3 (active tasks are tasks 2 and 3); dPC(S2)=2 (active tasks are tasks 3 and 4). T10: τ4
locked signal. The system priority upper limit is increased according to PCP, dSPC=dPC(S2)=2;
T15: τ2 and τ3 are released. Since τ2 has a higher priority than τ3 and τ4 and does not require a critical section initially, it is preempted and started running.
T25: τ2 locks the semaphore because its priority level 3 exceeds the current system priority upper limit 2, and then the system priority upper limit is increased to 3 according to PCP; τ2 activity criticality l2 is increased from LO to HI.
T30: τ1 is released and preempted.
T50: τ1 has been running for 20 time units and its WCET is estimated to be in LO-crit mode and has not yet completed, so the system undergoes a mode change from LO to MCP.
T60: τ1 completes execution, τ2 continues execution because its activity criticality is HI;
T65: τ2 releases the semaphore; its activity criticality falls back to LO, and according to AMC, it will terminate immediately. Since there are no longer active LO-crit tasks, the system enters HI-crit mode. The dynamic priority upper limit of semaphore S1 drops from 3 to 2; the system priority upper limit also drops to 2. τ3 starts running (activity priority is higher than τ4).
T75: τ3 requests semaphore S1. But even if S1 is idle, it will be blocked because its priority does not exceed dSPC=2; τ4 starts running and inherits τ3 active priority 2.
T80: τ4 releases S2; system priority cap drops to 0, but jumps back up to 2 as soon as τ3 locks S1,
After T80: τ3 continues running, locking and releasing the semaphore it needs because no other task is competing with it for the semaphore .
Note: In the rules of the protocol, the task with the highest activity priority is always selected. That is to say, if a task activity priority is 1, enters a critical section with priority 3, and executes for a period of time, it will still be A task with an active priority of 2 that does not require critical resources is preempted, but this task cannot enter any critical section because its current priority is less than the active system ceiling, and tasks with a priority of 1 at the beginning will be inherited when they are executed again. Priority level 2 is the priority of the task.
3.4 Calculation of the worst-case blocking time of the protocol
In the context of MCS, blocking can be divided into traditional priority inversion blocking (pi-blocking), caused by a lower priority task holding resources required by a higher priority task; or critical blocking. Turn blocking (ci-blocking), new blocking items caused by the LO-crit task holding the resources required by the HI-crit task during the mode change.
Personal opinion on why critical reversal blocking is defined separately during mode changes:
First, in LO mode, all tasks are executed with C (LO) as the execution limit, so tasks at both HI and LO levels can be completed on time. This is a feature of MCS;
In HI mode, AMC defines to abandon all LO tasks. In fact, if there are LO tasks mixed in and all tasks are executed in C (HI), some tasks will miss the deadline. During the mode conversion, there are still LO tasks being executed. In this sense, these tasks will cause blocking of high criticality, so it is necessary to calculate these.
For the schedulability analysis of AMC task sets, three situations need to be checked:
1) Verify the schedulability of LO-crit mode by calculating the WCRT of each task. In LO-crit mode, any task may experience pi-blocking. Use PBi^(LO) to represent the maximum pi-blocking time that can be experienced in LO-crit mode.
2) Verify the schedulability of the HI-crit mode by calculating the WCRT of each HI task. The principle is similar to 1). Use PBi^(HI) to represent the maximum pi-blocking time that can be experienced in LO-crit mode.
3) Verify schedulability during mode changes by calculating the WCRT of each HI task whose job is released during the LO-crit mode or mode change and is completed during the HI-crit mode or mode change, i.e. the job's There is some overlap between execution intervals and mode change cycles. During this period, any HI task may experience pi blocking from tasks in HI and LO; in addition, it may also experience ci blocking from the LO task. We use PBi^(MCP) (CBi^(MCP)) to represent the maximum pi blocking (ci blocking) time that can be experienced during a mode change cycle.
Define Zi,k to represent the longest critical part of task i protected by semaphore Sk; δi,k represents the duration of Zi,k.
3.4.1 Blocking time calculation in LO mode:
Here, consider tasks published and completed in LO-crit mode
Since task i can experience pi blocking at most once, the maximum pi blocking time that can be experienced in LO-crit mode is given by the length of the longest critical segment that can block (analogous to PCP).
Exactly the same as PCPbound. The difference between parameters Zi,k and δi,k here can be understood as Z is to find this area, and δ is the net calculation time.
3.4.2 Calculation of blocking time in HI mode:
Similarly, consider tasks published and completed in HI-crit mode
Nothing to say, exactly the same as the previous one.
3.4.3 Blocking time during mode transition
Define χ to represent the set of critical sections that may cause task i to block ci
Task i is blocked at most once by each task that can block ci on it. Therefore, the duration of the longest critical section among all critical sections that may cause ci to be blocked is added.
In addition, from another perspective, task i is blocked at most once by each critical section protected by a semaphore. Find all critical sections that may block it and add up the durations of the longest critical sections.
Then choose the smaller of the two.
In addition, since in LO-crit mode and during mode transition, τi can suffer from pi blocking from lPH(τi) and lpL(τi); in HI-crit mode, the HI-crit task can only experience pi blocking from lPH(τi) task. pi-blocking so there:
Therefore, the maximum total blocking time is the sum of equations (13) and (7).
4. Performance evaluation
The schedulable task set as a percentage of the task set CPU utilization and critical section length.
Details omitted