Round-robin scheduling is a CPU scheduling policy in which each ready task is given a fixed time slice (quantum) in turn, cycling through all tasks of equal priority repeatedly. When a task's quantum expires, the scheduler preempts it and moves it to the back of the ready queue, giving the next task its turn.
In practice
In bare-metal embedded systems, a simple round-robin loop is often implemented as a main loop that calls each task function in sequence (sometimes called a super-loop or cooperative dispatcher rather than a scheduler in the strict sense). Each "task" runs to completion before the next one starts, which keeps implementation trivial but means a slow task will delay all others. This cooperative variant is sometimes called a round-robin super-loop and is covered in depth in posts like "From Baremetal to RTOS: A review of scheduling techniques" and the "You Don't Need an RTOS" series.
In RTOS-based designs, round-robin scheduling typically applies only to tasks sharing the same priority level. FreeRTOS, for example, enables time-sliced round-robin among equal-priority tasks by default when configUSE_TIME_SLICING is set to 1, with the quantum equal to one tick period (whose duration depends on the configTICK_RATE_HZ setting and is commonly configured somewhere between 1 ms and 10 ms, but varies by port and application). Higher-priority tasks still preempt lower-priority ones immediately, so round-robin operates within a priority band, not across the entire task set.
A key pitfall is choosing an appropriate time quantum. A quantum that is too short increases context-switch overhead and can hurt determinism; one that is too long makes the system feel unresponsive and can cause missed deadlines for peer tasks. On resource-constrained MCUs where context switching carries measurable overhead (stack saves, and potentially pipeline effects), this tradeoff can be more pronounced than on many application processors, though the specifics depend heavily on the architecture of both the MCU and the processor being compared.
Round-robin alone does not typically provide hard real-time guarantees. Because any task in the same priority group may consume its full quantum before yielding, worst-case response time for a peer task scales with the number of tasks in the group multiplied by the quantum. It is possible to meet hard real-time requirements using round-robin if task budgets, group sizes, and worst-case execution times are tightly controlled, but for general hard real-time requirements, rate-monotonic or earliest-deadline-first scheduling is more appropriate. The post "Round-robin or RTOS for my embedded system" discusses the practical tradeoffs between a bare-metal round-robin loop and adopting a full RTOS.
Discussed on EmbeddedRelated
Frequently asked
What is the difference between cooperative and preemptive round-robin scheduling?
In cooperative round-robin, each task runs until it voluntarily yields control, so a task that blocks or runs long will stall the others. In
preemptive round-robin, a hardware timer
interrupt fires at the end of each quantum and the
scheduler forcibly switches to the next task, bounding the maximum time any one task can monopolize the CPU. Many RTOSes use preemptive round-robin among same-priority tasks, though not all do.
Does FreeRTOS use round-robin scheduling?
FreeRTOS uses a priority-based
preemptive scheduler, with optional time-sliced round-robin among tasks at the same priority level. Time slicing is enabled by setting configUSE_TIME_SLICING to 1 (the default in most ports), with the quantum equal to one RTOS tick period. Tasks at different priority levels are not round-robined; the highest-priority ready task always runs first.
Is a round-robin super-loop a real RTOS?
No. A round-robin super-loop is a bare-metal pattern with no OS kernel, no
preemption, and typically no priority mechanism. It is simpler and has lower overhead, but it offers no timing guarantees and no isolation between tasks. For many low-complexity embedded applications it is entirely adequate, as discussed in the 'You Don't Need an RTOS' series, but it does not provide the scheduling services an RTOS offers.
How does round-robin scheduling affect worst-case response time?
For a task in a round-robin group of N tasks each with quantum Q, the worst-case time before that task gets a turn is (N - 1) x Q, assuming all peers are always ready. This grows linearly with group size, which matters for soft real-time constraints. If predictable, bounded
latency is required, keep the number of same-priority tasks small, reduce the quantum, or assign distinct priorities so each task is scheduled deterministically.
When should I choose a round-robin super-loop over an RTOS?
A round-robin super-loop is a reasonable choice when the system has a small number of tasks with similar timing requirements, all tasks can complete within an acceptable period, and the overhead or licensing complexity of an RTOS is undesirable. It works well on simple 8-bit or 16-bit MCUs with limited
RAM where an RTOS
stack per task would be costly. Once tasks have significantly different priorities or blocking behavior, or hard deadlines must be enforced, a proper RTOS
scheduler becomes easier to reason about and maintain.
Differentiators vs similar concepts
Round-robin scheduling is often contrasted with priority-based
preemptive scheduling, where tasks run strictly in priority order and lower-priority tasks are blocked as long as any higher-priority task is ready. Pure priority scheduling can starve low-priority tasks indefinitely; round-robin among same-priority peers avoids starvation within a priority band. Round-robin is also distinct from
rate-monotonic scheduling (RMS) and earliest-deadline-first (EDF), which assign priorities based on task periods or deadlines and are designed to meet hard real-time guarantees. Most production RTOSes combine priority preemption with optional round-robin time-slicing at each priority level rather than using any single policy exclusively.
