Task management
Two different task concepts are provided by the OSEK operating system:
Basic Tasks
only release the processor, if
they terminate,
the OSEK operating system switches to a higher-priority task, or
an interrupt occurs which causes the processor to switch to an interrupt service routine (ISR).
Extended Tasks
allow to use the operating system call WaitEvent, which may result in a waiting state.
In view of the operating system, management of extended tasks is, in principal, more complex than management of basic tasks and requires more system resources.
1 Task state model
Extended task
basic task
2 Activating a task
Task activation is performed using the operating system services ActivateTask or ChainTask.
After activation the task is ready to execute from the first statement.
Multiple requesting of task activation
Depending on the conformance class a basic task can be activated once or multiple times.
"Multiple requesting of task activation" means that the OSEK operating system receives and records parallel activations of a basic task already activated.
The number of multiple requests in parallel is defined in a basic task specific attribute during system generation.
If the maximum number of multiple requests has not been reached, the request is queued.
The requests of basic task activations are queued per priority in activation order.
3 Task priority
The value 0 is defined as the lowest priority of a task. Accordingly bigger numbers define higher priorities.
To enhance efficiency, a dynamic priority management is not supported.
Accordingly priority of a task is definedstatically, i.e. the user cannot change it at the time of execution. However, in particular cases the operating system can treat a task with a defined higher priority (OSEK Priority Ceiling Protocol).
Tasks on the same priority level are started depending on their order of activation.
A preempted task is considered to be the first (oldest) task in the ready list of its current priority.
A task being released from the waiting state is treated like the last (newest) task in the ready queue of its priority.
4 Scheduling policy
Full preemptive scheduling
means that a task which is presently running may be rescheduled at any instruction by the occurrence of trigger conditions pre-set by the operating system.
Full preemptive scheduling will put the running task into the ready state, as soon as a higher-priority task has got ready.
The task context is saved so that the preempted task can be continued at the location where it was preempted.
If a task fragment shall not be preempted, this can be achieved by blocking the scheduler temporarily via the system service GetResource.
rescheduling is performed in all of the following cases:
Successful termination of a task (system service TerminateTask).
Successful termination of a task with explicit activating of a successor task (system service ChainTask).
Activating a task at task level (e.g. system service ActivateTask, message notification mechanism, alarm expiration).
Explicit wait call if a transition into the waiting state takes place (extended tasks only, system service WaitEvent).
Setting an event to a waiting task at task level (e.g. system service SetEvent, message notification mechanism, alarm expiration, if event setting defined).
Release of resource at task level (system service ReleaseResource)
Return from interrupt level to task level
Non preemptive scheduling
if task switching is only performed via one of a selection of explicitly defined system services (explicit points of rescheduling).
Non preemptive scheduling imposes particular constraints on the possible timing requirements of tasks.
Specifically the non preemptable section of a running task with lower priority delays the start of a task with higher priority up to the next point of rescheduling.
Points of rescheduling
rescheduling in the following cases:
Successful termination of a task (system service TerminateTask).
Successful termination of a task with explicit activation of a successor task (system service ChainTask).
Explicit call of scheduler (system service Schedule).
A transition into the waiting state takes place (system service WaitEvent).
Implementations of non preemptive systems may prescribe that operating system services which cause rescheduling may only be called at the highest task program level (not in task subfunctions).
A task switch at these points of scheduling usually requires saving of less task context information.
The definition of a non preemptable task makes sense in a full preemptive operating system
if the execution time of the task is in the same magnitude of the time of a task switch,
if RAM is to be used economically to provide space for saving the task context, or
if the task shall not be preempted.
Mixed preemptive scheduling
If preemptable and non preemptable tasks are mixed on the same system, the resulting policy is called "mixed preemptive" scheduling.
Many applications comprise only few parallel tasks with a long execution time, for which a full preemptive operating system would be convenient
and many short tasks with a defined execution time where non preemptive scheduling would be more efficient.
5 Termination of tasks
In the OSEK operating system, a task can only terminate itself ("self-termination").
The OSEK operating system provides the service ChainTask to ensure that a dedicated task activation is performed just after the termination of the running task.
Each task shall terminate itself at the end of its code.
Ending the task without a call to TerminateTask or ChainTask is strictly forbidden and causes undefined behaviour.