Real-Time Workshop

Multitasking Execution

In this section, we will consider the execution of the model when the solver mode is MultiTasking. Block computations are executed under two tasks, prioritized by rate:

• The slower task, which gets lower priority, is scheduled to run every second. We will refer to this as the 1 second task.
• The faster task, which gets higher priority, is scheduled to run 10 times per second. We will refer to this as the 0.1 second task. The 0.1 second task can preempt the 1 second task.

Table 8-2 shows, for each block in the model, the execution order, the task under which the block runs, and whether the block has an output or update computation.Blocks A and B do not have discrete states, and accordingly do not have an update computation.

Table 8-2: Task Allocation of Blocks in Multitasking Execution

Blocks (in Execution Order)	Task	Output	Update
F	0.1 second task	Y	Y
E	0.1 second task	Y	Y
D	Output promoted to run under 0.1 second task (see Block Priority Promotions) Update runs under 1 second task	Y	Y
A	0.1 second task	Y	N
B	Promoted to run under 0.1 second task (see Block Priority Promotions)	Y	N
C	1 second task	Y	Y

Real-Time Multitasking Execution

Figure 8-13 shows the scheduling of computations in MultiTasking solver mode when the generated code is deployed in a real-time system.The generated program is shown running in real time, as two tasks under control of interrupts from a 10 Hz timer.

Figure 8-13: Multitasking Execution of Model in a Real-Time System

Block Priority Promotions.   Notice following block "promotions":

• The rate-transition block B has been promoted to run at higher task priority, under the 0.1 second task. However, B still executes only at 1-second intervals, (that is, at every 10th tick of the 1-second task). In other words, B runs at the higher priority but at the slower rate.

• This promotion is required because C requires input from B. Running B at higher task priority ensures that the output computation of B is always completed before C needs it.

• The output computation for rate-transition block D has also been promoted to run at higher task priority, under the 0.1 second task. Like B, D's output still executes only at 1-second intervals.
• The update computation for block D runs under the lower-priority 1 second task, at the same priority as C. This is because the state of D is dependent upon the output of C.

On each tick, all the outputs and updates for the faster blocks must run before the lower-priority block (C) gets any run time. Only block C runs entirely in the 1 second task. In Figure 8-13, C does not complete its output computation within the first 0.1 second tick, so it is preempted by the higher-priority task at time 0.1. C then resumes and completes, at which point the update function for D is executed. There is then some idle time before the next tick.

If the computations for block C were to take longer than 1 second, an interrupt overflow error condition would exist.

Notice that in multitasking mode, the program makes more efficient use of time than in singletasking mode, as it spends less time in an idle state.

Simulated Multitasking Execution

Figure 8-14 shows the execution of the same model in Simulink, in MultiTasking solver mode. In this case, Simulink runs all blocks in one thread of execution, simulating multitasking. No preemption occurs.

Figure 8-14: Multitasking Execution of Model in Simulink

Singletasking Execution

Optimizing the Model for Code Generation