Method and apparatus for improving processing performance of a multi-core processor

Abstract

Managing task execution in a multi-core processor may be achieved by employing a spinlock and a multi-processor priority ceiling protocol. The spinlock may be employed to effect a dynamically enforceable mutual exclusion constraint. The multi-processor priority ceiling protocol may be employed to effect the dynamically enforceable mutual exclusion constraint to synchronize a plurality of tasks executing in the first and second processing cores of the multi-core processor.

Description

TECHNICAL FIELD

This disclosure is related to multi-core processors.

BACKGROUND

The statements in this section merely provide background information related to the present disclosure. Accordingly, such statements are not intended to constitute an admission of prior art.

Processors are electronic devices that are configured with central processing unit (CPU)(s) and associated memory and storage devices that execute routines to perform tasks. Performance of a processor may be improved by increasing clock speed of the CPU, thus resulting in faster execution of routines. There is an upper bound on clock speed and associated processor performance due to mechanical, electrical and thermal limitations of the processor hardware and interface devices.

Multi-core processors have been introduced to improve performance in executing routines to perform tasks. In such architectures, the presence of multiple processing cores enables the capability of true parallel task execution. However, tasks simultaneously executing on different cores may need to synchronize and/or coordinate with one another because of application-level requirements.

SUMMARY

A method for managing task execution in a multi-core processor includes employing a spinlock to effect a dynamically enforceable mutual exclusion constraint and employing a multi-processor priority ceiling protocol to effect the dynamically enforceable mutual exclusion constraint to synchronize a plurality of tasks executing in the first and second processing cores of the multi-core processor.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments will now be described, by way of example, with reference to the accompanying drawings, in which:

FIGS. 1-1 and 1-2 schematically show embodiments of exemplary multi-core processing systems that include first and second processing cores, in accordance with the disclosure;

FIG. 2-1 schematically shows a task execution diagram for executing a plurality of tasks in a multi-core processing system, in accordance with the disclosure;

FIG. 2-2 graphically shows a first timing graph associated with task execution in relationship to elapsed timesteps, in accordance with the disclosure;

FIG. 2-3 graphically shows a second timing graph associated with task execution employing a static offset shown in relationship to elapsed timesteps, in accordance with the disclosure;

FIG. 3 graphically shows a sensitivity evaluation of set/wait events for a baseline utilization and a maximum utilization plotted in relation to internal combustion engine speed, in accordance with the disclosure;

FIG. 4 schematically shows a process for analyzing timing of spinlocks, including first and second processing cores and shared software resource which is either acquired for execution or spinning, in accordance with the disclosure;

FIG. 5 graphically shows a timing graph associated with task execution employing spinlocks, shown in relationship to elapsed timesteps in accordance with the disclosure;

FIG. 6 graphically shows a sensitivity evaluation of spinlocks for a baseline utilization and a maximum utilization, plotted in relation to internal combustion engine speed in accordance with the disclosure;

FIG. 7 schematically shows implementation of a multi-processor priority ceiling protocol, including first and second processing cores and corresponding first and second priority queues leading to a shared priority queue that is executed by a shared software resource in accordance with the disclosure; and

FIG. 8 graphically shows a timing graph associated with execution of the multi-processor priority ceiling protocol in accordance with the disclosure.

DETAILED DESCRIPTION

Referring now to the drawings, wherein the showings are for the purpose of illustrating certain exemplary embodiments only and not for the purpose of limiting the same, FIGS. 1-1 and 1-2 schematically illustrate embodiments of multi-core processing systems that include first and second processing cores. The multi-core processing systems described herein including first and second processing cores are illustrative and not restrictive. Furthermore, the terms ‘first’ and ‘second’ are employed to identify and differentiate specific processing cores, but are not employed to indicate an order of precedence or preference. The multi-core processing system preferably is a homogeneous multi-core processor, although the disclosure is not so limited. The concepts described herein apply to any multi-core processing system that employs two or more processing cores.

FIG. 1-1 shows a first embodiment of a homogeneous multi-core processor 10, which is preferably a single chip element including first and second processing cores 12 and 22, respectively, first and second architecture states 13 and 23, respectively, and individual first and second on-chip L1 memory caches 14 and 24, respectively. Other features include thermal controllers 30, programmable interrupt controllers (APIC) 32, and power management logic 34. A second shared memory cache 36 and bus interface 38 are employed to communicate with an external bus 40.

FIG. 1-2 shows a second embodiment of a homogeneous multi-core processor 50, which is preferably a single chip element including first and second processing cores 52 and 62, respectively, and individual first and second on-chip L1 memory caches 54 and 64, respectively. Other features include a system request interface 66, a cross-bar switch 67, and first and second memory controllers 58 and 68, respectively, which are used to manage communications with external devices including communications via external bus 40 in one embodiment. The first and second embodiments of the homogeneous multi-core processor 10 and 50 are illustrative.

Each of a plurality of tasks Ti includes a sequence of runnables, wherein m(i) denotes the number of runnables belonging to task Ti. The individual runnables are denoted as R_i,1 through R_i,m(i). The worst-case execution time of each runnable R_i,j is assumed to be known and denoted as C_i,j. The cumulative worst-case execution time of task Ti is the sum of all constituent runnable execution times, which is denoted as C, (i.e., C_i=C_i,1+C_i,2+ . . . +C_i,m(i). The term P(Ti) denotes the processing core to which task Ti is assigned. The first runnable R_i,1 of any task Ti is assumed to be either triggered periodically every Ti or by an event E_i,1 set by another task with period Ti. All subsequent runnables R_i,j(j>1) are assumed to be triggered by either the completion of the previous runnable R_i,j-1 or an external event E_i,j. Each runnable R_i,j is also given an offset O_i,j>0 such that the runnable is eligible to execute only after O_i,j time units have elapsed since the corresponding release of R_i,1.

The runnable that triggers or sets an event E_i,j is denoted by π_i,j. In the scenario that a runnable R_i,j (j>1) is triggered by the previous runnable R_i,j-1 then E_i,j is set by π_i,j=R_i,j-1. For convenience, π_i,j=O for any runnable R_i,1 that is assumed to be triggered periodically every Ti. Each task has a deadline equal to its period Ti. This assumption follows from the fact that another iteration of task Ti will start if Ti does not complete in Ti time units. The priority assignment is assumed to follow rate-monotonic scheduling. Tasks with shorter periods are assigned higher scheduling priorities. Without loss of generality, the task set is given in non-decreasing order of periods and increasing order of priorities. The term hp(Ti) is employed to denote the set of tasks with higher priority than Ti, and lp(Ti) is employed to denote the set of tasks with lower priority than Ti. The term p(Ti) is employed to denote the priority of task Ti. For any lock M protecting a mutually exclusive shared resource, the term I(M) is employed to denote the number of tasks that access lock M, and C_M is employed to represent the maximum duration for which M can be held.

Synchronization structures such as precedence constraints may be realized using events for multi-core precedence constraints. By way of example, two tasks are considered, including task T1 executing on processing core P1 and task T2 executing on processing core P2. The application requires a runnable R_2,d of task T2 to start execution after the completion of a runnable R_1,s of task T1. In this scenario, runnable R_2,d on P2 can be made to Pend/Wait on an event E_2,d, which can in turn be set by the completion of runnable R_1,s on P1. Set/wait events are employed to statically enforce mutual exclusion constraints by enforcing precedence relationships between runnables in different tasks running on the same core, and are generalized to the context of multi-core processors.

Analysis of tasks with set/wait events includes developing a response-time analysis for such tasks. By way of example, a task T1 on processing core P with runnables R_i,1 through R_i,m(i) that uses set/wait events is evaluated. In one scenario none of the higher priority tasks Th (i.e., higher priority than Ti) on P use set/wait events to synchronize with other tasks, i.e., ∀Th εhp(Ti) and ∀k>1, π_h,k=R_h,k-1. In this scenario, a bound on the worst-case response time of task Ti can be derived, as follows. Let F(R_i,j) denote an upper bound on the finish time of runnable R_i,j. In order to calculate F(R_i,j), the last runnable R_i,e of Ti before R_i,j is employed, which was triggered by an external event, i.e., e<j is the largest value such that e=1 or π_i,e≠R_i,e. The time instant at which this external event is set can be denoted as S_i,e. If W_{i,{e . . . j}} denotes the worst-case response time of the Ti segment including runnables R_i,e through R_i,j, then F(R_i,j) is determined as follows.F(R_i,j)=S_i,e+W_{i,{e . . . j}}  [1]

The finish time of runnable R_i,j is thus no more than W_{i,{e . . . j}} from the setting of event E_i,e at S_i,e.

An upper bound on the worst-case response time W_{i,{e . . . j}} can be obtained under the assumption that none of the higher-priority tasks on processing core P use external set/wait events. The worst-case response time W_{i,{e . . . j}} is calculated by using the standard response-time test, which is the convergence of the following:

$\begin{array}{cc}{W}_{i,\left\{e\dots j\right\}}^{v+1}=\sum _{q=e}^j{C}_{i,q}+\sum _{\forall \mathrm{Th}\in \mathrm{hp}\left(\mathrm{Ti}\right)\&P\left(\mathrm{Th}\right)=P\left(\mathrm{Ti}\right)}\left[\frac{W_{i,\left\{e\dots j\right\}}^v}{T_h}\right]C_h\mathrm{wherein}{W}_{i,\left\{e\dots j\right\}}^0=\sum _{q=e}^j{C}_{i,q}& \left[2\right]\end{array}$

Assuming that runnables set their corresponding events by the end of their execution, the result includes the following.S_i,e=F(π_i,e)  [3]This operation is shown with reference to FIGS. 2-1, 2-2, and 2-3.

FIG. 2-1 schematically shows a task execution diagram for executing a plurality of tasks in a multi-core processing system, e.g., as described with reference to FIGS. 1-1 and 1-2. The executed tasks include T1210, T2220, T3230, and T4240. T1210 includes sequentially executed runnables R_1,1 211, R_1,2 212, R_1,3 213, and is executed by the first processing core. As shown, T1210 is scheduled for execution once every four timesteps, and each runnable executes in a single timestep. T2220 includes sequentially executed runnables R_2,1 221 and R_2,2 222, and is executed by the first processing core. As shown, T2220 is scheduled for execution once every seven timesteps, and each runnable executes in a single timestep. T1210 has a higher priority than T2220, and thus will take precedence in execution in the first processing core. T3230 includes a single runnable R_3,1 231 and is executed by the second processing core. As shown, T3230 is scheduled for execution once every three timesteps, and each runnable executes in a single timestep. T4240 includes a single runnable R_4,1 241 and is executed by the second processing core. As shown, T4240 is scheduled for execution once every four timesteps, and each runnable executes in a single timestep. T3230 has a higher priority than T4240, and thus will take precedence in execution in the second processing core. The first and second processing cores 20 and 30 are each configured to execute one task runnable at a time. T2220 and T3230 are able to be executed without set/wait event constraints. T1210 and T4240 each have a set/wait event constraint, which is a precedence relationship wherein execution of runnable R_1,2 212 cannot be initiated until complete execution of runnable R_1,1 211 of T1210 in the first processing core, as shown by connector 215 and runnable R_4,1 241 of T4240 in the second processing core, as shown by connector 245. Runnable R_4,1 is triggered by an event E_4,1 set by runnable R_2,3, i.e., R_4,1=R_2,3. Similarly, runnable R_2,4 is triggered by an event E_2,4 set by runnable R_4,1, i.e., R_2,4=R_4,1. As can be seen, the worst-case response time of each internally triggered contiguous segment is calculated to bound the overall task response time. The finish time F(R_2,3) of runnable R_2,3 is computed as the worst-case response time of the segment R_2,1 through R_2,3 using convergence described with reference to EQ. 2. This is then used as the setting time of event E_4,1 using EQ. 3. The worst-case response time of segment runnable R_4,1 is calculated using the convergence of EQ. 2. Again using EQS. 1 and 3, the finishing time of runnable R_4,1 is calculated as F(R_4,1). Using this finishing time value in EQ. 1 and the worst-case response time of segment R_2,4 through R_2,5 obtained using convergence of EQ. 2, the finishing time of runnable R_2,5 is obtained. This is also an upper bound on the worst-case response time of T2220. Although the analysis provides an upper bound on the worst-case response time of tasks using set/wait events, the bounds can be pessimistic due to the assumption of independent worst-case response times for each contiguous segment of internally-triggered runnables. Also, the set/wait events structures often lead to larger worst-case response times that are due to the potential for long delays in setting events. For instance, in the example shown in FIG. 2-1, wherein T2220 has to account for the preemption of T4 by T2230 since this leads to a delay in setting E_2,4. Thus, it may be beneficial both from analysis and performance perspectives to avoid set/wait event structures if possible to ensure the task set is schedulable at higher utilization thresholds or alternatively utilizing slower (and therefore) cheaper processors. A consequence of using set/wait events is that the release of runnables is no longer guaranteed to be periodic. Depending on the setting time S_i,e of external events, the release time of runnable R_i,e changes. This leads to jitter and scheduling penalties for lower-priority tasks. This can be avoided by statically assigning appropriate offsets to the runnables that are triggered by external events.

FIG. 2-2 graphically shows the first timing graph associated with execution of the tasks T1210, T2220, T3230, and T4240 that are described with reference to FIG. 2-1 in relationship to elapsed timesteps shown on the x-axis 250. No static offsets are employed. Executions of task runnables are shown starting at timestep 0. As the timesteps progress, runnables of T1210, T2220, T3230, and T4240 are executed. Tasks T1210 and T2220 are assigned to first processing core while tasks T3230 and T4240 are assigned to second processing core. T1210 and T4240 synchronize with each other using set/wait events. T1210 is made up of runnables R_1,1, R_1,2, and R_1,3. T4240 is made up of a single runnable R_4,1. T1210 and T4240 are triggered periodically every 4 time units. Runnable R_1,2 is eligible to execute after the completion of R_1,1 and it is triggered by an external event E_1,2 set by R_4,1, i.e., T_1,2=R_4,1. As for the other tasks, T2220 has two runnables R_2,1 and R_2,2 with a period of 7 time units, and T2230 has a single runnable R_3,1 with a period of 3 time units. For simplicity of presentation, all runnables are assumed to have a worst-case execution time of 1 time unit.

In the scenario shown in FIG. 2-2, the release jitter of runnable R_1,2 causes T2220 to miss its deadline of 7 time units. It can be seen that R_1,2 was delayed on event E_1,2 during the first release of T1210, while it was not delayed during the second release. This causes an increased preemption on T2220, which leads to T2220 missing its deadline.

A mechanism includes assigning release offsets in addition to the event triggers to address release jitter. By way of example, a runnable triggered by an external event E_i,e is evaluated. The event E_i,e is guaranteed to be set by the worst-case finish time F(π_i,e) of the runnable π_i,e setting Ei,e. Therefore, assigning a static offset of Φ_i,e=F (π_i,e) guarantees that the event E_i,e is set before runnable R_i,e starts executing. Static offsets thus act as a simple period enforcer, which allows for a periodic release of runnable R_i,e and relieves tasks with lower priority than task Ti from dealing with the release jitter of runnable R_i,e. If runnables are not assigned such static offsets, it may lead to longer worst-case response times and unpredictable runnable release times during system operation.

Details of the operation depicted in FIG. 2-2 include as follows. At timestep 0, runnable R_1,1 211 of T1210 executes in the first processing core and runnable R_3,1 231 of T2230 coincidentally executes in the second processing core. At timestep 1, runnable R_2,1 221 of T2220 executes in the first processing core and runnable R_4,1 241 of T4240 executes in the second processing core. T1210 is delayed in executing because runnable R_1,2 212 of T1210 is awaiting execution of runnable R_4,1 241 of T4240 in the second processing core, which is a required condition precedent for execution of runnable R_1,2 212 of T1210 which has lower priority than runnable R_3,1 231 of T2230. At timestep 2, runnable R_1,2 212 of T1210 executes in the first processing core after completed executions of the condition precedents of runnable R_1,1 211 of T1210 and runnable R_4,1 241 of T4240. At timestep 3, runnable R_3,1 231 of T2230 executes again in the second processing core in response to its scheduled execution that occurs every three timesteps. Element R_1,3 213 of T1210 executes in the first processing core, thus completing an iteration of T1210. At timestep 4, another iteration of T1210 executes in the first processing core in response to its scheduled execution that occurs every four timesteps. Thus, at timestep 4, runnable R_1,1 211 of T1210 executes. Simultaneously, runnable R_4,1 241 of T4240 executes in the second processing core because runnable R_3,1 231 of T2230 has previously executed and the second processing core is available to so execute.

The simultaneous execution of runnable R_1,1 211 of T1210 and runnable R_4,1 241 of T4240 allows execution of runnable R_1,2 212 of T1210 at timestep 5 followed by execution of runnable R_1,3 213 of T1210 at timestep 6. This action precludes execution of runnable R_2,2 222 of T2220 due to its lower priority in the first processing core. Thus, T2220 fails to execute in its allotted time period, and a fault ensues, as indicated by element 235.

FIG. 2-3 graphically shows the second timing graph associated with execution of tasks T1210, T2220, T3230, and T4240 that are described with reference to FIG. 2-1 in relationship to elapsed timesteps shown on the x-axis 250 and employing static offset in T1210. T1210 is able to employ a static offset because it has three task runnables and four timesteps in which to complete its task. Executions of the task runnables are shown starting at timestep 0. As the timesteps progress, runnables of T1210, T2220, T3230, and T4240 execute as follows. At timestep 0, runnable R_1,1 211 of T1210 executes in the first processing core and runnable R_3,1 231 of T2230 coincidentally executes in the second processing core. A static offset 214 is introduced into T1210 after execution of runnable R_1,1 211 during every iteration of T1210. Introducing the static offset 214 after execution of runnable R_1,1 211 is permissible because T1210 has three task runnables and four timesteps in which to complete its task, thus introducing the static offset 214 will not interfere with complete execution of T1210. Thus, at timestep 1, T1210 is delayed in executing in response to introduction of the static offset 214. Element R_4,1 241 of T4240 executes in the second processing core, which has lower priority than runnable R_3,1 231 of T2230. Introducing the static offset 214 after execution of runnable R_1,1 211 is preferred because execution of runnable R_4,1 241 of T4240 is a required condition precedent thereto and runnable R_4,1 241 of T4240 executes in the second processing core at a lower priority than runnable R_3,1 231 of T2230. At timestep 2, runnable R_1,2 212 of T1210 executes in the first processing core after completed executions of the condition precedents of runnable R_1,1 211 of T1210 and runnable R_4,1 241 of T4240. At timestep 3, runnable R_3,1 231 of T2230 executes again in the second processing core in response to its scheduled execution that occurs every three timesteps. Element R_1,3 213 of T1210 executes in the first processing core, thus completing an iteration of T1210. At timestep 4, another iteration of T1210 executes in the first processing core in response to its scheduled execution that occurs every four timesteps. Thus, at timestep 4, runnable R_1,1 211 of T1210 executes. Simultaneously, runnable R_4,1 241 of T4240 executes in the second processing core because runnable R_3,1 231 of T2230 has previously executed and the second processing core is available to so execute. At timestep 5, T1210 is delayed in executing in response to introduction of the static offset 214. This permits runnable R_2,2 222 of T2220 to execute in the first processing core at timestep 5, thus completing execution of T2220 within the scheduled execution that is commanded every seven timesteps. Thus there is no delay in execution of T2220, and no attendant delay in response times of systems awaiting the outcome of T2220. At timestep 6, runnable R_1,2 212 of T1210 executes in the first processing core and runnable R_3,1 231 of T2230 executes again in the second processing core in response to its scheduled execution that occurs every three timesteps. At timestep 7, runnable R_1,3 213 of T1210 executes in the first processing core, thus completing another iteration of T1210.

Introducing the static offset 214 after execution of runnable R_1,1 211 frees a timestep in the first processing core during which lower priority T2220 may execute its runnable. Thus, introducing the static offset 214 after execution of runnable R_1,1 211 increases the likelihood that lower priority T2220 executes its runnables in a timely manner without affecting response time of execution of T1210. Furthermore, introducing the static offset 214 improves timing predictability of lower priority tasks, e.g., T2220.

FIG. 3 graphically shows a sensitivity evaluation of set/wait events for a baseline utilization 315 and a maximum utilization 325, plotted in relation to internal combustion engine speed, shown on the x-axis 310. Utilization is shown on the y-axis 320. In order to evaluate the timing analysis using set/wait events, an example system with ten time-triggered tasks and two engine synchronous tasks was considered and evaluated. Relevant to the set/wait event mechanism are two pairs of tasks: (i) primary and secondary tasks with periods of 6.25 ms, and (ii) primary and secondary tasks with periods of 12.5 ms. Task pair (i) has 5 runnables while task pair (ii) has 68 runnables. Task pair (i) has 1 set/wait event structure, while task pair (ii) has 30 set/wait event structures. A timing analysis of this setup was executed on a dual-core system using the analysis. In the sensitivity evaluation, the execution times of tasks increase until the analysis computes that some task in the system just misses its deadline. The system utilization was noted at this load as the maximum achievable utilization for the given operating point. Given that there are two engine synchronous tasks, the engine speed was varied from 3500 RPM to 5750 RPM while measuring maximum achievable utilization. The results indicated that set/wait event structures affect utilization and the system is unable to exceed 52% utilization even when the baseline system has a high utilization. By contrast, if the system did not have such set/wait event structures but the same worst-case execution times, the system utilization can be increased by 127% at 3500 RPM and increased by 124% at 5750 RPM. This means that the system is schedulable at higher utilization thresholds. This has three implications: additional tasks can use the CPU processing power, or alternatively, a slower CPU can be employed, or alternatively, processors with fewer processing cores can be employed. Note that the utilization of a resource can never be higher than 100%. What is meant is that the current utilization at which the system is schedulable can be increased by, for instance, a factor of 1.27. If the current utilization is 60%, then an additional 7% (60%*1.27) of the processor utilization can be employed by up-integrating additional tasks. In other words, the system is still scheduled at 67% utilization. Other factors may affect utilization, including inherent delays introduced by set/wait event structures.

A spinlock primitive may be employed as a mechanism for run-time inter-core task synchronization in a multi-core operating system. A spinlock is a synchronization mechanism wherein a processing thread waits in a loop or spins while waiting to synchronize. The thread remains active but is not performing a useful task. Once acquired, a spinlock is held until released unless synchronization or another action releases the lock.

As described herein, runnables are required to acquire a spinlock before accessing any shared resource. If a resource is currently being used and the spinlock is being held, then the runnable requesting this resource continues to spin (nm) on the lock until it is released or until it is preempted by another higher priority runnable on the same core. However, a spinning runnable can be preempted. This acts as a dynamic run-time mechanism for mutual exclusion. A spinlock can be employed to improve system utilization by avoiding the overhead introduced by set/wait events. Shared logic resources can be protected across multiple processing cores using the spinlock primitive. Tasks accessing any mutually-exclusive shared resource may hold the spinlock before doing so. If a task tries to acquire a spinlock that is currently being held by some other task, the task spins or busy waits on the lock until it is released by the task. This mechanism thus provides support for realizing mutual exclusion of a shared resource in a multi-core processor.

In multi-core processor architectures, both spinlocks and set/wait events may be employed. For tasks where the mutual exclusion constraints need to be statically enforced, set/wait events are employed. For tasks where the mutual exclusion constraints can be dynamically enforced, spinlocks and/or a multi-processor priority ceiling protocol (MPCP) may be employed. For example, a system with multiple sensors and actuators, where the processing is handled on a dual-core processor is evaluated. The processing tasks themselves may use set/wait event constraints for statically defined mutual exclusion. The sensor and actuator data handling tasks might use run-time mutual exclusion primitives for ensuring consistent data readings. Although spinlocks successfully ensure mutual exclusion from a functional perspective, they may pose multiple problems from a timing perspective. Timing challenges associated with spinlocks include deadlocks, priority inversion, and starvation. A deadlock occurs when a task holding a lock is preempted by a higher-priority task which requires the same lock. In this case, the higher-priority task requesting the resource will be spinning or busy waiting forever. One solution to address this issue is to place design constraints that prevent tasks on the same processing core from using spinlocks.

A priority inversion occurs when a high-priority task waits for a low-priority task to release a resource. The use of spinlocks can lead to an unbounded duration of priority inversion, which presents a significant challenge to tasks with strict deadlines. In situations where there are many medium-priority tasks and multiple preemptions on a task, a high-priority task may end up facing an unbounded amount of priority inversion. Priority inversion is a more serious problem with spinlocks since the high-priority tasks are basically busy-waiting/wasting cycles on their processing cores. Long durations of priority inversion thus lead to significant loss in useful system utilization. Bounding such priority inversion is important to achieve both timing predictability and better utilization.

Starvation occurs when a task is starved from getting access to the shared resource. In one example, a spinlock is acquired and released back-and-forth between lower-priority tasks even though a higher-priority task is waiting on it. This sequence is possible when a hardware test-and-set implementation is not guaranteed to respect task priorities. When using spinlocks, starvation can arise because the hardware scheduling of test-and-set operations can be more favorable to certain processing cores, or the task spinning on the lock might be preempted on its processing core whenever the lock gets released by other tasks. As with the nature of spinlocks, the busy waiting during such starvation also leads to utilization loss from wasted processor cycles.

Task response-times with spinlocks can be determined for achieving bounded timing behavior that takes into consideration design constraints and assumptions. This includes using the analysis provided in EQS. 1, 2, and 3 by adding spinning time to account for the lock-waiting delays and a blocking time for the non-preemptive duration of lower-priority tasks. The blocking terms are calculated as follows. A lock-waiting delay is determined using the previously described set of design constraints. Each time a mutually exclusive task, i.e., a mutually exclusive event (mutex) M is requested by a Runnable R_i,j of task Ti, the lock-waiting time using spinlocks is restricted to a lock-waiting delay of (I(M)−1)CM, wherein CM is the maximum lock-holding time. A cumulative spinning time CI(i,j) can be calculated for each task Ti. A mutex is a process that ensures that no two processes or processing threads access a shared logic resource, e.g., shared memory cache or location, during the same time period, thus preventing corruption of the shared resource. A non-preemptive duration is determined for each event which includes each periodically-triggered runnable R_i,j of each task Ti. A non-preemptive duration Bn(i, j) of lower-priority tasks is bounded by using the maximum non-preemptive duration, which is determined as a maximum I(M)CM over all mutexes M that can be held by any task with lower priority than Ti. The lower-priority task is assumed to be non-preemptive over this entire duration. For runnables R_i,j (j>1) that are triggered by the completion of previous runnable R_i,j (j>1), the non-preemptive blocking duration Bn(i, j) is set as 0.

The spinning term CI(i,j) is added to the worst-case execution time of each runnable R_i,j for all tasks (including the higher-priority tasks). The blocking term Bn(i,j) needs to only be applied for the task Ti, whose response time is calculated using EQ. 2. The aforementioned analysis described is thus extended to include the use of spinlocks.

FIG. 4 schematically shows a process for analyzing timing of spinlocks, including first and second processing cores 410 and 420 respectively, and shared software resource 430 that is either acquired for execution 415 or spinning 425. This allows introduction of design constraints to enable a timing analysis and allows development of timing analysis with the design constraints in place.

FIG. 5 graphically shows a timing graph associated with task execution employing spinlocks, shown in relationship to elapsed timesteps. Tasks are shown coincidentally in relation to elapsed time on the x-axis 505, and include Task T1510 attempting to execute on a second processing core, Task T2520 attempting to execute on a first processing core, and Task T3530 attempting to execute on the first processing core. Initially, T3530 is in a busy/waiting mode 515 with a lock-held state 525 employing a suspend-all-interrupt function 545. At timestep 540, T1510 enters a busy/waiting mode 515, which changes to the lock-held state at timestep 550 and employs remote blocking. T2520 begins operating in a pre-emptive blocking mode 535 at timestep 550. Thus, to bound busy-waiting periods, the control system employs a suspend-all-interrupt function before acquiring any spinlock, thus enabling interrupts only after releasing the spinlock. Successive requests to any spinlock M are spaced out in time by I(M)CM, wherein I(M) is a quantity of tasks accessing the spinlock M and CM is the maximum duration for which M is held, i.e., lock-holding time.

FIG. 6 graphically shows a sensitivity evaluation of spinlocks for a baseline utilization 615 and a maximum utilization 625, plotted in relation to engine speed, shown on the x-axis 610. Utilization is shown on the y-axis 620. In this case global logic resources to be shared across the dual-core processor are introduced. A minimum of 2 tasks per resource and a maximum of 3 tasks per resource were employed, with no more than 2 resources per task. The percentage of time spent by each task was increased on each of its global critical sections until the system was determined analytically to just miss its deadline. The set/wait event structures were ignored. As can be seen in these results, the system performs quite well allowing each task to spend up to 50% of its execution time on globally shared resources.

Placing a restrictive set of design constraints can lead to bounded response times with spinlocks. However, the spinlock mechanism still does not ensure a priority-ordered service of resource requests. In order to relax the assumptions and ensure a priority-driven service, a multi-processor priority ceiling protocol (MPCP) may be employed. The MPCP is employed for task synchronization in a multi-core processor to achieve a priority-ordered service of resource requests by relaxing assumptions. Terms of interest include a global mutex M_G, which is a mutex shared by tasks deployed on different processing cores. The corresponding critical sections are referred to as global critical sections (GCS). Conversely, a local mutex is only shared between tasks on the same processing core, and the corresponding critical sections are local critical sections. When a task T acquires M_G, it executes the GCS corresponding to the global mutex M_G at a priority that is set as follows:p(M_G)=p(G)+p(T0)wherein

• • p(M_G) is a priority ceiling,
  • p(G) is a base priority level greater than that of any other normally executing task in the system, and
  • p(T0) is the priority of a highest priority task T0 that can lock the global mutex M_G.

Each MPCP minimizes remote blocking and priority inversions when global resources are shared. Each MPCP includes the following characteristics, including tasks use assigned priorities unless within critical sections, and a single processor priority ceiling protocol is used for all requests to local mutexes. A task within a global critical section (GCS) guarded by global mutex M_G has the priority of its GCS, i.e., (p(G)+p(T0)). A task within a GCS can preempt another task T* within a GCS if the priority of the GCS for T0 is greater than the priority of the GCS for T*. When a task T requests a global mutex M_G, the global mutex M_G can be granted to T by means of an atomic transaction on shared memory if M_G is not held by another task. If a request for a global mutex M_G cannot be granted, the task T is added to a prioritized queue on M_G before being preempted. The priority used as the key for queue insertion is the normal priority assigned to T. When a task T attempts to release a global mutex M_G, the highest priority task Th waiting for M_G is signaled and becomes eligible for execution at Th's host processing core at its GCS priority. If no tasks are suspended on global mutex M_G, it is released.

FIG. 7 schematically shows implementation of a multi-processor priority ceiling protocol, including first and second processing cores 710 and 720, respectively, having corresponding first and second priority queues 705 and 715 respectively, which leads to a shared priority queue 725 that is executed by a shared software resource 730. Each global mutex maintains a priority queue of tasks waiting to acquire it. When a task acquires the global mutex, it is ready to execute on its corresponding processing core at the remote priority ceiling of the global mutex. Priority is established as a maximum of all task normal execution priorities and a maximum of all normal priorities of tasks accessing the shared software resource, which is described herein.

FIG. 8 graphically shows a timing graph associated with execution of the multi-processor priority ceiling protocol. There are four tasks in this system, including T1810, T2820, T3830, and T4840. Tasks T1810 and T2820 are assigned to the same processing core P1. Task T3830 is assigned to a second processing core P2. Task T4840 is assigned to a third processing core P3. Tasks T1810 and T4840 share a logic resource using a first global mutex M1. Tasks T2820 and T3830 share a different logic resource using a second global mutex M2. Each of the tasks T1810, T2820, T3830, and T4840 includes normal execution 825 and critical execution 815, with critical execution 825 corresponding to tasks that have high priority. Initially, tasks T1810, T2820, and T4840 are in normal execution 825. At timestep 850, T4840 begins critical execution 815. At timestep 852, T3830 begins critical execution 815, and T2820 begins normal execution 825, which ends at timestep 854. T2820 requests the global mutex M2, which it acquires when the second global mutex M2 is released by T3830 at timestep 856, thus allowing T2 to execute with critical execution 815. When T2820 completes executing at the remote priority ceiling of second global mutex M2, the first global mutex M1 with higher remote priority ceiling is released by T4840 at timestep 858 and priority is given to T1810. This causes a preemption of T2820 by T1810, even though T2820 is holding second global mutex M2, since the first global mutex M1 has a higher remote priority ceiling than the second global mutex M2. At timestep 860, T1810 completes the critical execution 815, which allows T2820 to operate with critical execution 815, ending at timestep 862. The multi-processor priority ceiling protocol thus allows tasks holding global mutexes to be preempted by higher-priority global mutexes, which is beneficial in reducing the lock-waiting delays and lock-holding times of global mutexes accessed by high-priority tasks.

A benefit of using the multi-processor priority ceiling protocol includes permitting priority-driven access to shared resources, wherein each global mutex has a priority queue of tasks suspended on it. When the resource is released, it is given to the highest priority task waiting on it. This property is not provided by spinlocks, which allows the hardware test-and-set primitives to determine the task that gets the resource. Another benefit of using the multi-processor priority ceiling protocol includes a restricted preemption of tasks that are holding locks. Under MPCP, a global priority ceiling p(G) is employed that allows for tasks holding mutexes to be preempted by mutexes with a higher remote priority ceiling, wherein p(M_G) represents the remote priority ceiling. This ensures the responsiveness of highest priority tasks that may have short deadlines.

Another benefit of using the multi-processor priority ceiling protocol includes no cycles wasted in a busy waiting mode, including in a suspension-based implementation of MPCP where tasks are allowed to suspend when the requested lock is not available. The task is added to a priority queue on the mutex and it is notified when the resource is granted. This avoids any cycles wasted in busy waiting. However, the task suspension itself introduces the possibility of lower-priority tasks executing and requesting global mutexes. This may lead to preemptions from such tasks at a later point of execution. In order to avoid such a penalty, a spin-based implementation of MPCP can be employed where tasks spin on the requested lock until it is available.

The aforementioned response-time test for tasks with set/wait events can be readily extended to handle synchronization with MPCP. Blocking terms are defined for a global-mutex-waiting delay, and a lower-priority global-mutex-holding duration. The global-mutex-waiting delays are described as follows. The tasks acquire global mutexes in priority order with the MPCP. The mutex can thus be viewed as a resource scheduled in a fixed-priority order. Blocking time BMi,j of a runnable Ri,j of task Ti accessing a global mutex M is defined as follows.

$\begin{array}{cc}{B}_{i,j}^{M,q+1}=\underset{\mathrm{Tl}\in \mathrm{lp}\left(\mathrm{Tl}\right)\mathrm{and}\mathrm{Tl}\in M}{\max }1*W_l^M+\sum _{\mathrm{Th}\in \mathrm{hp}\left(\mathrm{Tl}\right)\mathrm{and}\mathrm{Th}\in M}\left(\frac{B_{i,j}^{M,q}}{\mathrm{Th}}+1\right)*W_h^{\prime M}\mathrm{wherein}{B}_{i,j}^{M,0}=\underset{\mathrm{Tl}\in \mathrm{lp}\left(\mathrm{Tl}\right)\mathrm{and}\mathrm{Tl}\in M}{\max }1*W_l^{\prime M}& \left[4\right]\end{array}$

The first term corresponds to the maximum duration for which the mutex M can be held by any lower-priority task Tl when Ti requests M. The second term represents the maximum duration for which higher-priority tasks Th can hold the mutex M before task Ti can acquire M. Here, W′_l^M is the maximum global-mutex-holding time of task Tl with respect to global mutex M. Under MPCP, tasks holding the global mutex M can still be preempted by tasks holding mutexes with higher remote priority ceiling. The maximum global-mutex-holding time of task Tl is thus given by the convergence as follows.

$\begin{array}{cc}{W}_l^M=\mathrm{CM}+\sum _{\forall \mathrm{Tk}||P\left(\mathrm{Tk}\right)=P\left(\mathrm{Ti}\right)}\underset{\forall M^{\prime }||\mathrm{Tk}\in M^{\prime }\mathrm{and}p\left(M^{\prime }\right)>p\left(M\right)}{\max }{\mathrm{CM}}^{\prime }& \left[5\right]\end{array}$

In EQ. 5, the first term CM represents the worst-case execution time when holding the global mutex M. The second term represents the maximum preemption possible when Ti is holding the global mutex M by tasks Tk on the same processing core as Ti when they acquire mutexes M′ with higher remote priority ceilings than the global mutex M.

The total global-mutex-waiting delay B_i,j for runnable R_i,j is determined by summing the blocking times BM_i,j for each access from T_i,j over all mutexes M. Bi is represented as the sum of waiting delays B_i,j over all runnables R_i,j belonging to task Ti.

A lower-priority global-mutex-holding duration is determined as follows. Whenever a task Tl with lower priority than Ti acquires a global mutex M, its priority gets promoted to the remote priority ceiling of M. This remote priority ceiling is defined to be above all normal execution priorities and hence causes a preemption of Ti even if Ti is not holding any locks. This preemption from the lower-priority global-mutex-holding duration can be accommodated by the blocking term H_i,j for each runnable R_i,j. If R_i,j is triggered externally and it acquires ρ_i,j global mutexes during execution, as follows.

$\begin{array}{cc}{H}_{i,j}\left({\rho }_{i,j}+1\right)\sum _{\forall \mathrm{Tk}||P\left(\mathrm{Tk}\right)=P\left(\mathrm{Ti}\right)\mathrm{and}\mathrm{Tk}\in \mathrm{lp}\left(\mathrm{Ti}\right)}\underset{\forall M^{\prime }||\mathrm{Tk}\in M^{\prime }}{\max }{\mathrm{CM}}^{\prime }& \left[6\right]\end{array}$

If R_i,j (with j>1) is triggered by the completion of R_i,j-1 and it acquires ρ_i,j global mutexes during execution, then:

$\begin{array}{cc}{H}_{i,j}\left({\rho }_{i,j}\right)\sum _{\forall \mathrm{Tk}||P\left(\mathrm{Tk}\right)=P\left(\mathrm{Ti}\right)\mathrm{and}\mathrm{Tk}\in \mathrm{lp}\left(\mathrm{Ti}\right)}\underset{\forall M^{\prime }||\mathrm{Tk}\in M^{\prime }}{\max }{\mathrm{CM}}^{\prime }& \left[7\right]\end{array}$

The total lower-priority global-mutex-holding duration Hi experienced by task Ti can be calculated by summing up the H_i,j over all runnables R_i,j belonging to task Ti.

The worst-case response-time convergence given in EQ. 2 can be modified as follows.

$\begin{array}{cc}{W}_{i,\left\{e\dots j\right\}}^{v+1}=\sum _{q=e}^j\left(C_{i,q}+B_{i,q}+H_{i,q}\right)+\sum _{\forall \mathrm{Th}||\mathrm{hp}\left(\mathrm{Ti}\right)\mathrm{and}P\left(\mathrm{Th}\right)=P\left(\mathrm{Ti}\right)}\frac{W_{i,\left\{e\dots j\right\}}^{v+1}+\mathrm{Bh}}{\mathrm{Th}}*\mathrm{Ch}& \left[8\right]\end{array}$

The analysis thus includes mutual exclusion using the Multi-processor Priority Ceiling Protocol (MPCP). In addition to providing priority-driven service and bounded timing properties, the use of MPCP eliminates the constraints and assumptions required for spinlocks.

The disclosure has described certain preferred embodiments and modifications thereto. Further modifications and alterations may occur to others upon reading and understanding the specification. Therefore, it is intended that the disclosure not be limited to the particular embodiment(s) disclosed as the best mode contemplated for carrying out this disclosure, but that the disclosure will include all embodiments falling within the scope of the appended claims.

Claims

1. A method for managing task execution in a multi-core processor, comprising: employing a spinlock to effect a dynamically enforceable mutual exclusion constraint; andemploying a multi-processor priority ceiling protocol to effect the dynamically enforceable mutual exclusion constraint to synchronize a plurality of tasks executing in the first and second processing cores of the multi-core processor; wherein employing the multi-processor priority ceiling protocol comprises employing a global priority ceiling to preempt tasks having selected mutual exclusion constraints by a task having a mutual exclusion constraint having a higher remote priority ceiling, including executing global critical sections corresponding to a global mutex MG when a task T acquires the global mutex MG at a set priority.

2. The method of claim 1, wherein employing a global priority ceiling to preempt tasks having selected mutual exclusion constraints by a task having a mutual exclusion constraint having a higher remote priority ceiling including executing global critical sections corresponding to a global mutex MG when a task T acquires the global mutex MG at a set priority further comprises the set priority being set in accordance with the following relationship: p(MG)=p(G)+p(T0)

3. The method of claim 2, wherein the global mutex MG is a mutex shared by tasks deployed in different ones of the first and second processing cores of the multi-core processor.

4. A method for managing task execution in a multi-core processor, comprising: executing a runnable of a task in a first processing core of the multi-core processor including introducing a static offset for another runnable of a task executing in a second processing core of the multi-core processor to effect a statically defined mutual exclusion constraint across said runnables;employing a spinlock to effect a dynamically enforceable mutual exclusion constraint and employing a multi-processor priority ceiling protocol to effect the dynamically enforceable mutual exclusion constraint to synchronize a plurality of tasks executing in the first and second processing cores of the multi-core processor; wherein employing the multi-processor priority ceiling protocol comprises employing a global priority ceiling to preempt tasks having selected mutual exclusion constraints by a task having a mutual exclusion constraint having a higher remote priority ceiling, including executing global critical sections corresponding to a global mutex when a task acquires the global mutex at a set priority.

5. A method for managing task execution in a multi-core processor, comprising: executing a runnable of a task in a first processing core including introducing a static offset for another runnable of a task executing in a second processing core to effect a statically defined mutual exclusion constraint across said runnables; andselectively employing spinlocks, set/wait events, and multi-processor priority ceiling protocols to effect mutual exclusion constraints to synchronize a plurality of tasks executing in the first and second processing cores;wherein employing multi-processor priority ceiling protocols comprises employing a global priority ceiling to preempt tasks having selected mutual exclusion constraints by a task having a mutual exclusion constraint with a higher priority ceiling, including executing global critical sections corresponding to a global mutex MG when a task T acquires the global mutex MG at a set priority.

6. The method of claim 5, wherein employing set/wait events statically enforce the mutual exclusion constraints.

7. The method of claim 5, wherein employing spinlocks and the multi-processor priority ceiling protocols dynamically enforce the mutual exclusion constraints.

8. The method of claim 5, wherein employing the global priority ceiling to preempt tasks having selected mutual exclusion constraints by a task having a mutual exclusion constraint with a higher priority ceiling, including executing global critical sections corresponding to a global mutex MG when a task T acquires the global mutex MG at a set priority further comprises the set priority being set in accordance with the following relationship: p(MG)=p(G)+p(T0)

9. The method of claim 8, wherein the global mutex MG is a mutex shared by tasks deployed in each of the first and second processing cores of the multi-core processor.

10. The method of claim 5, wherein employing the multi-processor priority ceiling protocols comprises assigning priority to a task within a global critical section guarded by a global mutex with a priority of the global critical section.

11. The method of claim 10, wherein employing the multi-processor priority ceiling protocols further comprises permitting a first task within the global critical section to preempt a second task within the global critical section when a priority of the first task is greater than a priority of the second task.

12. The method of claim 11, wherein employing the multi-processor priority ceiling protocols further comprises granting a global mutex to a task using an atomic transaction in shared memory of the multi-core processor when the global mutex is not held by another task.

13. The method of claim 12, wherein employing the multi-processor priority ceiling protocols further comprises adding a task to a prioritized queue on the global mutex before preempting the task when a request for a global mutex cannot be granted, wherein a priority for the task added to the prioritized queue is pre-assigned.

14. The method of claim 13, wherein employing the multi-processor priority ceiling protocols further comprises making a highest priority task eligible for execution in a host processing core for the highest priority task at the global critical section priority for the highest priority task when a task attempts to release the global mutex.

15. The method of claim 14, wherein employing the multi-processor priority ceiling protocols further comprises pre-assigning priorities to tasks outside global critical sections.

16. The method of claim 15, wherein employing the multi-processor priority ceiling protocols further comprises employing a single processor priority ceiling protocol for a request to a local mutex.