simulate scheduler of a multicore control system -凯发k8网页登录

functional components includes two closed-loop systems. each has a proportional controller operating a plant.

architectural components includes simevents blocks modeling the tasks and scheduler of this control system.

id: unique identifier of a task.

period: how frequently a task is instantiated for execution.

priority: priority of the task (smaller value indicates higher priority).

list of runnable segments (functions): executables associated with each segment of the task. these executables are represented by simulink functions of an exported function model.

segment execution duration: time for a task segment to complete, if it is executed on a processor without interruption.

needs disk i/o resource for each segment: whether a segment of the task requires the use of a mutex-protected shared resource (a hard disk).

task creation: block task 1 and task 2 create tasks and manage task states. a simevents entity represents an instance of a task. properties of a task (such as its priority) are modelled as entity attributes.

task queue: upon instantiation, a task joins a ready task queue, which is modelled by the entity queue block os task queue. to simulate a non-preemptive priority-based scheduling policy, the queue block is configured to sort tasks by the taskpriority attribute.

cpu: the processor of the system is modelled as an entity server block cpu. it accepts entities from the os task queue and processes the entity for a duration as specified by the task's segment execution duration parameter. at the end of this delay, the corresponding simulink function of this task segment is called, as a part of the block's service complete action.

lock/unlock mutex: before a task segment enters the block cpu, it must acquire the required resource at the preceding lock mutex block. after the task segment completes and exits the block cpu, the resource is released at the unlock mutex block.

managing task states: blocks under the mask of task 1 and task 2 manage the run-time state of tasks. upon completion of a task segment, if the task has subsequent segments to execute, the task is routed back to the os task queue. otherwise, this task instance is completed and discarded.

the higher priority task, task 2 (red bars), is scheduled to core 1 (y = 1).

the lower priority task, task 1 (blue bars), is scheduled to core 2 (y = 2).

the second segment of task 2 uses the mutex disklock. green bars indicate the usage (y = 3).

in block cpu, configure parameter capacity to change the number of cores.

in blocks task 1 and task 2, configure parameters such as period and priority to change task specifications.

both tasks have segments that use mutex disklock, as indicated by green bars (y = 3).

the third segment of task 1 now must execute in a serial fashion with the second segment of task 2 (see y = 1), because both segments share the mutex disklock.