In real-time systems, the software’s different functionalities are conveniently divided into different units/entities called TASKS. The task provides the frameworks for the execution of functions and the OS is responsible for running the sequence of different tasks using the scheduler.
Task model
The task entity in the OSEK environment is defined with a number of properties (ex, stack size, extended/basic, preemptive/non-preemptive…etc.). through which it may affect the system behavior and size of the executable generated file.
In OSEK operating system, There are 2 types that can be used when defining a task:
- Basic tasks
- Extended tasks
The difference between basic and extended tasks is in the state machine for each one. For basic tasks, the below state machine is applied.
If the task is in running mode the CPU will be allocated/assigned to this task and its code can be executed. At a specific point in time, a single task only can use the processor (single-core system) and being in running state while other tasks can be in different other states.
The task will be in the ready state when all of the conditions of moving to the running state are achieved but another task is a higher priority and running. The scheduler entity is responsible for selecting a specific task at each scheduling point and move to running state.
If the task is suspended, it might be considered in a passive state and it will not be executed or chosen by the scheduler at any scheduling point in order to run.
The different task state transitions are clarified in the below table:
Transition | Previous state | Next state | Details |
Activate | Suspended | Ready | The task can be activated using a system service call (ActivateTask(), ChainTask()..)
|
Start | Ready | Running | The highest priority task is chosen by the scheduler to start the execution in any scheduling point. |
Terminate | Running | Suspended | The task can be activated using a system service call (TerminateTask(), ChainTask()..)
|
Preempt | Running | Ready | At any scheduling point the scheduler might select a higher priority task to run and move the currently running task to the ready queue. |
The same states and transitions are applied to Extended tasks however, the extended task has one more state which is the waiting state.
In waiting state, the extended task is waiting for an event (or a set of events) to occurs and then it will continue from where it was moved to wait state. Below there are 2 more transitions applicable for extended tasks only.
Transition | Previous state | Next state | Details |
Wait | Running | Waiting | The task will move to the wait state using a system service call (ie. WaitEvent() )
|
Release | Waiting | Ready | The task will be moved to ready state if the event that the task waiting for is set. The scheduler is responsible to run/start the highest priority ready task. |
It is up to the system designer and SW architect to set each task to be extended or basic. Once this property is set for each task this can not be changed at runtime.
Check Useful Courses On OSEK RTOS:
Scheduling policy
Usually, the scheduler entity is described as preemptive or non-preemptive. In OSEK based environments the presentability attribute is assigned to the task entity itself which means each task in the system shall be configured as a preemptive or non-preemptive task where the preemptive task can be preempted if a higher priority task gets ready while the non-preemptive task cannot be preempted by a higher priority task.
Based on the previous, OSEK OS might have different scheduling policies:
1.
Full preemptive scheduling system:
Scheduling points will be performed if:
- Termination of the current task (the running task terminate itself using TerminateTask() system service call or using ChainTask() request)
- Activating another task using ActivateTask() system service call or Alarm firing (not covered in the article)
- Waiting request call from the running task context where the scheduler has to select another task to run.
- Setting a specific event for an extended task.
- Releasing a resource from the task context. (ie. ReleaseResource() system service call.).
2.
Non-preemptive scheduling system:
Scheduling points will be performed if:
- Termination of the current task (the running task terminate itself using TerminateTask() system service call or using ChainTask() request)
- Activating another task using ActivateTask() system service call or Alarm firing (not covered in the article)
- Waiting request call from the running task context where the scheduler has to select another task to run.
- Explicit call of scheduler ie. Schedule() to enforce a scheduling point.
3.
Mixed scheduling system:
If the system includes preemptive task and non-preemptive task at the same time. The result is mixed preemptive scheduling policy. In this case the scheduling points depend on the current running task. If the running task is preemptive then the full preemptive scheduling system is performed while if the running task is non-preemptive then the non-preemptive scheduling system is performed.
Task Services Summary:
API | Description |
StatusType ActivateTask ( TaskType ID ) | Task ID is moved from suspended state to ready state. The OS will make sure that the task starts from the first statement. |
StatusType TerminateTask ( void ) | The service will terminate the caller task and the task will be moved to the suspended state |
StatusType ChainTask ( TaskType ID) | Task ID is moved from suspended state to ready state. The caller task will be terminated and moved to the suspended state. |
StatusType Schedule ( void ) | This is an explicit request to call the scheduler. If a higher priority task is ready then the caller task will be moved to the ready state and the highest priority task will be moved to running state. Otherwise, the caller task will be continued. |
StatusType GetTaskID ( TaskRefType TaskID) | This service will get the task ID of the current running task. |
StatusType GetTaskState ( TaskType ID, TaskStateRefType State) | To get the state of a specific task at the time of calling. |