Scheduling

Introduction

In this stage I design a Round Robin scheduling system to design CPU time for the differents tasks.

This task distribution assign a certain time to each task (named Quantum); after that time the schedule algorithm searches another task to assign a new quantum. Also, a task manager is needed; for the moment only exists a task_creation interface.

For a example, you can watch the following link.

Design

For design this Round Robin, we need a data structure that saves a certain state of a task, some logical control for the scheduling process and the capability for change the machine state. Also, is important to save some statics for a task, like the total ticks, total time elapsed, total transitions from ready to run, to be able to perform some perform analytic and adjust the Quantum.

The task struct

A task is defined by the PC register, the SP and the safety-registers (a convention designs x19 to x30 safety registers). Our task struct needs to save this registers in memory with some control and identification information, useful for the scheduling logic.

The scheduling logic

The scheduling logic is called every time a timer interrupt occurs. In this code, we need to update the scheduling data (in our case the Quantum but we can add other variables). After that, we need to control if the current task has run out all the quantum, in that case, we need to search a new task to run and change the execution context Also, for this Real Time OS, a task can control the preemption (in the future will be implemented). This is a very important feature, because for some uses is important to don't allow it.

Jumping to a new state - Task switch

For change the context, an assembler entry is needed, because we need to restore the values of all the safety registers and the PC. This entry will be called by the scheduler if a task switch is required.

Implementation

For a detailed implementation, about all the design concepts from above you can read the page about.

All together

In this point, the OS can run several threads/tasks, that share memory (there isn't any restrictions about) and resources (UART). For avoid data-races in the future a synchronization API for lock/unlock resources is needed. Also, the choice of the Quantum is a very important factor, depending the use. For the moment, the OS works like this:

In addition, in real time it would be interesting to add a method to suggest the system a task switch.

The next step is to define some system calls (SYSCALL) and a user space to allow a user run code in a safety mode and programed in a high-level.