RTOS Terms: Process, Task, Release Time, Execution Time and More

Why Learn RTOS Terminology?

If you are getting started with Real-Time Operating Systems (RTOS) like FreeRTOS, Zephyr, or RTEMS, you will encounter specific terminology that can be confusing. Many of these terms have precise definitions that differ from general computing.

Understanding these terms clearly is essential because RTOS design decisions around scheduling, priority, and timing are all based on these concepts. This article provides clear definitions with examples for the most important RTOS terms.

Task (Thread)

A task (also called a thread) is the basic unit of execution in an RTOS. Each task is an independent piece of code that the RTOS scheduler can run. Tasks have their own:

• Stack: Local variables and function call history
• Program counter: Where execution currently is
• Priority: How important the task is relative to others
• State: Running, Ready, Blocked, or Suspended

// FreeRTOS task example
void vSensorTask(void *pvParameters) {
    while (1) {
        float temp = read_sensor();
        send_to_queue(temp);
        vTaskDelay(pdMS_TO_TICKS(1000));  // Run every 1 second
    }
}

// Create the task
xTaskCreate(vSensorTask, "Sensor", 256, NULL, 2, NULL);

A task runs in an infinite loop. The RTOS scheduler decides when each task gets CPU time.

Process vs Task

In general-purpose operating systems (Linux, Windows), a process is a program with its own memory space, and a thread is a unit of execution within a process. Processes are isolated from each other.

In most embedded RTOS environments, there are no processes in this sense. All tasks share the same memory space. The terms “task” and “thread” are often used interchangeably.

Task States

A task in an RTOS is always in one of four states:

1. Running: The task is currently executing on the CPU. Only one task can be in the Running state at a time (on a single-core processor).

2. Ready: The task is ready to run but is waiting for the scheduler to give it CPU time. A higher-priority task may be currently running.

3. Blocked: The task is waiting for an event, such as a delay completing, data arriving in a queue, or a semaphore becoming available. Blocked tasks do not consume CPU time.

4. Suspended: The task has been explicitly paused by another task or by itself. It will not run until explicitly resumed.

        +----------+    Scheduler selects    +---------+
        |  Ready   | -------------------->  | Running |
        +----------+                         +---------+
             ^                                  |   |
             |     Preempted by higher          |   |
             +------  priority task  -----------+   |
             |                                      |
             |         Wait for event               |
             |         (delay, queue, semaphore)    |
             |                                      v
             |                               +---------+
             +------  Event occurred  -------| Blocked |
                                             +---------+

Release Time (Arrival Time)

The release time (also called arrival time) is the moment when a task becomes ready to execute. This is when the task “arrives” in the ready queue.

For periodic tasks, the release time occurs at regular intervals:

Task: Read sensor every 100ms

Release times: 0ms, 100ms, 200ms, 300ms, 400ms, ...

Each release is called a "job" or "instance" of the task.

For aperiodic tasks (event-driven), the release time is unpredictable. For example, a task triggered by a button press can arrive at any time.

Execution Time (Computation Time)

The execution time (also called computation time or WCET – Worst-Case Execution Time) is the time a task actually needs the CPU to complete its work for one instance.

Task: Read sensor and process data
  - Execution time: 5ms
  - Period: 100ms

This means the task needs 5ms of CPU time out of every 100ms.

The Worst-Case Execution Time (WCET) is especially important because real-time systems must guarantee that all deadlines are met, even in the worst case.

Deadline

The deadline is the time by which a task must complete its execution. Missing a deadline has different consequences depending on the type of real-time system:

Hard real-time: Missing a deadline is a system failure. Examples: airbag deployment, anti-lock braking.

Firm real-time: Missing a deadline makes the result useless, but does not cause catastrophic failure. Example: video frame that arrives too late is dropped.

Soft real-time: Missing a deadline degrades quality but is still acceptable. Example: audio streaming has brief glitch.

Task: Control motor position
  - Period: 10ms
  - Execution time: 2ms
  - Deadline: 10ms (must complete before next period)

Timeline:
|---EXEC---|                    |---EXEC---|
0    2     10                   10   12    20
^Release   ^Deadline            ^Release   ^Deadline

Period

The period is the time interval between consecutive release times of a periodic task. It defines how often the task needs to run.

Examples:
  - Motor control loop: Period = 1ms (1000 Hz)
  - Sensor reading: Period = 100ms (10 Hz)
  - Display update: Period = 33ms (30 Hz)
  - Heartbeat LED: Period = 500ms (2 Hz)

Response Time

The response time is the total time from when a task is released to when it finishes execution. It includes:

Response Time = Waiting Time + Execution Time

Where:
  Waiting Time = Time spent in the Ready queue
                 (waiting for higher-priority tasks)
  Execution Time = Actual CPU time used

For a system to meet deadlines: Response Time must be less than or equal to Deadline.

Latency

Latency is the delay between an event occurring and the system responding to it. There are two key types:

Interrupt latency: Time between an interrupt signal and the start of the interrupt service routine (ISR). Depends on the CPU and current state.

Scheduling latency: Time between a task becoming Ready and actually starting to Run. Depends on higher-priority tasks and the scheduler.

Event (e.g., button press)
  |
  |--[Interrupt Latency]--|--[ISR executes]--|--[Scheduling Latency]--|--[Task runs]--|
  |                       |                  |                        |               |
  t0                     t1                 t2                       t3              t4

Total latency = t3 - t0

Priority

Each task has a priority that tells the scheduler how important it is. In a preemptive RTOS, a higher-priority task that becomes Ready will immediately interrupt a lower-priority running task.

// FreeRTOS: higher number = higher priority
xTaskCreate(vMotorControl,  "Motor",   256, NULL, 5, NULL);  // Highest
xTaskCreate(vSensorRead,    "Sensor",  256, NULL, 3, NULL);  // Medium
xTaskCreate(vDisplayUpdate, "Display", 256, NULL, 1, NULL);  // Lowest

Priority assignment guidelines:

• Safety-critical tasks: Highest priority
• Control loops: High priority
• Sensor reading: Medium priority
• Display/logging: Low priority
• Idle/background: Lowest priority

Context Switch

A context switch is when the RTOS saves the state of the currently running task (registers, program counter, stack pointer) and restores the state of another task to run it. Context switches happen when:

• A higher-priority task becomes Ready (preemption)
• The running task blocks (waiting for a delay, queue, or semaphore)
• The running task yields the CPU voluntarily
• The time slice expires (in round-robin scheduling)

Context switches have overhead (typically 1-10 microseconds on ARM Cortex-M). Too many context switches waste CPU time.

Jitter

Jitter is the variation in timing of a periodic task. If a task should run every 10ms but actually runs at 10ms, 10.5ms, 9.8ms, 10.2ms, the jitter is the deviation from the ideal timing.

Ideal:   |    10ms    |    10ms    |    10ms    |
Actual:  |   10.2ms   |   9.8ms    |   10.5ms   |
Jitter:     +0.2ms      -0.2ms       +0.5ms

Low jitter is critical for:

• Motor control (smooth motion)
• Audio sampling (no distortion)
• Communication protocols (accurate timing)

CPU Utilization

CPU utilization is the percentage of time the CPU spends executing tasks (as opposed to being idle).

Utilization = Sum of (Execution Time / Period) for all tasks

Example:
  Task A: Execution = 2ms, Period = 10ms  ->  0.20
  Task B: Execution = 3ms, Period = 20ms  ->  0.15
  Task C: Execution = 1ms, Period = 50ms  ->  0.02

  Total Utilization = 0.20 + 0.15 + 0.02 = 0.37 = 37%

As a rule of thumb, CPU utilization should stay below 70-80% to leave headroom for interrupt handling and occasional worst-case scenarios.

Summary Table

Understanding these terms builds the foundation for working with any RTOS. When you read about scheduling algorithms, priority inversion, or timing analysis, these definitions are what everything builds upon.

Vivek Bhageria

Vivek Bhageria — Lead Firmware R&D Engineer, 12+ years. Ex-Bosch (automotive powertrain), MusicTribe (real-time audio), medical devices. M.Tech BITS Pilani. I write at NerdyElectronics — practical, register-level embedded systems for engineers who want to understand what’s actually happening under the hood.

nerdyelectronics.com/about/