Main Content

Modeling for Multitasking Execution

Multitasking and Pseudomultitasking Modes

When periodic tasks execute in a multitasking mode, by default the blocks with the fastest sample rates are executed by the task with the highest priority, the next fastest blocks are executed by a task with the next higher priority, and so on. Time available in between the processing of high-priority tasks is used for processing lower priority tasks. This results in efficient program execution.

Where tasks are asynchronous rather than periodic, there may not necessarily be a relationship between sample rates and task priorities; the task with the highest priority need not have the fastest sample rate. You specify asynchronous task priorities using Async Interrupt and Task Sync blocks. You can switch the sense of what priority numbers mean by selecting or clearing model configuration parameter Higher priority value indicates higher task priority.

In multitasking environments (that is, under a real-time operating system), you can define separate tasks and assign them priorities. For bare-metal target hardware (that is, no real-time operating system present), you cannot create separate tasks. However, generated application modules implement what is effectively a multitasking execution scheme using overlapped interrupts, accompanied by programmatic context switching.

This means an interrupt can occur while another interrupt is currently in progress. When this happens, the current interrupt is preempted, the floating-point unit (FPU) context is saved, and the higher priority interrupt executes its higher priority (that is, faster sample rate) code. Once complete, control is returned to the preempted ISR.

The next figures illustrate how timing of tasks in multirate systems are handled by the code generator in multitasking, pseudomultitasking, and single-tasking environments.

The next figure shows how overlapped interrupts are used to implement pseudomultitasking. In this case, Interrupt 0 does not return until after Interrupts 1, 2, and 3.

Build a Program for Multitasking Execution

To use multitasking execution, select model configuration parameter Treat each discrete rate as a separate task. This parameter is active only if you set Solver type to Fixed-step. Auto mode results in a multitasking environment if your model has two or more different sample times. A model with a continuous and a discrete sample time runs in single-tasking mode if the fixed-step size is equal to the discrete sample time.

Execute Multitasking Models

In cases where the continuous part of a model executes at a rate that is different from the discrete part, or a model has blocks with different sample rates, the Simulink® engine assigns each block a task identifier (tid) to associate the block with the task that executes at the block's sample rate.

You set sample rates and their constraints on the Solver pane of the Model Configuration Parameters dialog box. To generate code, select Fixed-step for the solver type. Certain restrictions apply to the sample rates that you can use:

  • The sample rate of a block must be an integer multiple of the base (that is, the fastest) sample period.

  • When you set model configuration parameter Periodic sample time constraint to unconstrained, the base sample period is determined by the setting of parameter Fixed step size.

  • When you set parameter Periodic sample time constraint to Specified, the base rate fixed-step size is the first element of the sample time matrix that you specify for parameter Sample time properties. The Solver pane from the example model rtwdemo_mrmtbb shows an example.

  • Continuous blocks execute by using an integration algorithm that runs at the base sample rate. The base sample period is the greatest common denominator of rates in the model only when you set model configuration parameter Periodic sample time constraint to Unconstrained and parameter Fixed step size to Auto.

  • The continuous and discrete parts of the model can execute at different rates only if the discrete part is executed at the same or a slower rate than the continuous part and is an integer multiple of the base sample rate.

Multitasking Execution

This example examines how a simple multirate model executes in both real time and simulation, using a fixed-step solver. It considers operation in both single-tasking and multitasking modes, as determined by setting model configuration parameter Treat each discrete rate as a separate task.

The example model is shown in the next figure. The discussion refers to the six blocks of the model as A through F, as labeled in the block diagram.

The execution order of the blocks (indicated in the upper right of each block) has been forced into the order shown by assigning higher priorities to blocks F, E, and D. The ordering shown is one possible valid execution ordering for this model. For more information, see Simulation Phases in Dynamic Systems.

The execution order is determined by data dependencies between blocks. In a real-time system, the execution order determines the order in which blocks execute within a given time interval or task. This discussion treats the model's execution order as a given, because it is concerned with the allocation of block computations to tasks, and the scheduling of task execution.

Note

The discussion and timing diagrams in this section are based on the assumption that the Rate Transition blocks are used in the default (protected) mode, with block parameters Ensure data integrity during data transfer and Ensure deterministic data transfer (maximum delay) selected

This example considers the execution of the preceding model when model configuration parameter Tasking mode is set to MultiTasking. Block computations are executed under two tasks, prioritized by rate:

  • The slower task, which gets the lower priority, is scheduled to run every second. This is called the 1 second task.

  • The faster task, which gets higher priority, is scheduled to run 10 times per second. This is called the 0.1 second task. The 0.1 second task can preempt the 1 second task.

The following table 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.

Task Allocation of Blocks in Multitasking Execution

Blocks
(in Execution Order)

Task

Output

Update

E

0.1 second task

Y

Y

F

0.1 second task

Y

Y

D

The Rate Transition block uses port-based sample times.
Output runs at the output port sample time under 0.1 second task.
Update runs at input port sample time under 1 second task.
For more information on port-based sample times, see Referenced Model Sample Times.

Y

Y

A

0.1 second task

Y

N

B

The Rate Transition block uses port-based sample times.
Output runs at the output port sample time under 0.1 second task.
For more information on port-based sample times, see Referenced Model Sample Times.

Y

N

C

1 second task

Y

Y

Real-Time Multitasking Execution

The next figure 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.

Simulated Multitasking Execution

The next figure shows the Simulink execution of the same model, in MultiTasking solver mode. In this case, the Simulink engine runs the blocks in one thread of execution, simulating multitasking. No preemption occurs.

Related Topics