RTEMS C User's Guide
Tasks in an RTEMS system must always be in one of the five allowable task states. These states are: executing, ready, blocked, dormant, and non-existent.
A task occupies the non-existent state before a
rtems_task_create has been
issued on its behalf. A task enters the
non-existent state from any other state in the system when it is
deleted with the
directive. While a task occupies
this state it does not have a TCB or a task ID assigned to it;
therefore, no other tasks in the system may reference this task.
When a task is created via the
it enters the dormant state. This state is not entered through
any other means. Although the task exists in the system, it
cannot actively compete for system resources. It will remain in
the dormant state until it is started via the
directive, at which time it enters the ready state. The task is
now permitted to be scheduled for the processor and to compete
for other system resources.
A task occupies the blocked state whenever it is
unable to be scheduled to run. A running task may block itself
or be blocked by other tasks in the system. The running task
blocks itself through voluntary operations that cause the task
to wait. The only way a task can block a task other than itself
is with the
A task enters the blocked state due to any of the following conditions:
rtems_task_suspenddirective which blocks either itself or another task in the system.
rtems_message_queue_receivedirective with the wait option and the message queue is empty.
rtems_event_receivedirective with the wait option and the currently pending events do not satisfy the request.
rtems_semaphore_obtaindirective with the wait option and the requested semaphore is unavailable.
rtems_task_wake_afterdirective which blocks the task for the given time interval. If the time interval specified is zero, the task yields the processor and remains in the ready state.
rtems_task_wake_whendirective which blocks the task until the requested date and time arrives.
rtems_region_get_segmentdirective with the wait option and there is not an available segment large enough to satisfy the task's request.
rtems_rate_monotonic_perioddirective and must wait for the specified rate monotonic period to conclude.
A blocked task may also be suspended. Therefore, both the suspension and the blocking condition must be removed before the task becomes ready to run again.
A task occupies the ready state when it is able to be scheduled to run, but currently does not have control of the processor. Tasks of the same or higher priority will yield the processor by either becoming blocked, completing their timeslice, or being deleted. All tasks with the same priority will execute in FIFO order. A task enters the ready state due to any of the following conditions:
rtems_task_resumedirective for a task that is suspended and the task is not blocked waiting on any resource.
rtems_message_queue_broadcast, or a
rtems_message_queue_urgentdirective which posts a message to the queue on which the blocked task is waiting.
rtems_event_senddirective which sends an event condition to a task which is blocked waiting on that event condition.
rtems_semaphore_releasedirective which releases the semaphore on which the blocked task is waiting.
rtems_region_return_segmentdirective which releases a segment to the region on which the blocked task is waiting and a resulting segment is large enough to satisfy the task's request.
rtems_task_restartdirective for the blocked task.
A ready task occupies the executing state when it has control of the CPU. A task enters the executing state due to any of the following conditions:
RTEMS C User's Guide
Copyright © 1988-2004 OAR Corporation