Real-Time Kernels and Operating Systems

Operating System: Software that coordinates multiple tasks in processor, including peripheral interfacing Types of task activities: data exchange / sharing synchronization scheduling resource sharing Real-time OS (RTOS): one or more tasks must execute within specified time constraints

fig_11_00 Example: tasks in meal preparation cannot all be completed in a strict sequence

Single process/task: required resources: Process stack Memory address space Registers (in CPU) PC I/O ports and network connections File descriptors … Process state: PC value, register contents, etc. at a given time Which must be shared with other processes? How can this sharing be managed efficiently?

fig_11_01 In embedded systems we can think of the CPU as a resource for the current task: CPU is a shared resource Multitasking: more than one task needs to execute, in a seamless manner CPU, other resources must be shared

fig_11_02 Multiple processes, typically running concurrently Q: what are some typical processes?

fig_11_03 Tasks switch from “running” to “ready/waiting” and back according to a schedule Q: what should be length of turn? Who gets priority?

Common sharing strategies: Multiprogramming: task runs until it needs to wait on an external event (e.g., I/O) Real-time: certain tasks have deadlines that must be met Time-sharing: each process gets a time slice; processes are preempted when time slice is up, must wait for next turn

fig_11_04 Task context: what is the state of task—e.g., register contents; when tasks are swapped, contexts must also be swapped and task that is not running must have its information saved Task states In simple system

Thread: smallest set of resources a task needs (PC and stack, e.g.—if not running, must have copy of register contents) Terminology: Process= “heavyweight thread” Smallest set of resources = “lightweight thread”

fig_11_05 Single-thread design: one process

fig_11_05 Multiple threads

fig_11_07 Process privilege levels affect operations it can carry out without assistance from other processes: Child process: shares code space, has own data space, data, status, stack Multiple threads: each has its own stack, status information Process: separate address space Reentrant code: child process can use same code, needs different local variables

fig_11_07 Foreground tasks: initiated by interrupt or real-time constraint—higher priority levels Background tasks—not interrupt-driven—lower priority levels—e.g. monitoring tasks, intensive processing tasks

fig_11_07 Operating system: Kernel—portion of OS providing basic functions: Scheduler: Schedule tasks for execution Dispatcher: Choose (“dispatch”) task to run Intertask and interprocess communication: Ensure tasks can communicate as needed and are synchronized as needed

fig_11_07 Necessary services to carry out these jobs: Manage processes and tasks, deal with “deadlocks” Manage memory, I/O system, file system RTOS: make sure deadlines are met; make sure behavior is DETERMINISTIC (not necessarily “fast”) Hard real-time; system delays are known or at least bounded Soft real-time: critical tasks have priority and are allowed to run to completion

fig_11_08 OS architecture: Virtual machine model: Very modular but may not match real machine

fig_11_09 OS architecture: Typical architecture

fig_11_10 TCB: task control block—required for each task or process to be executed Task states: Ready Execute dormant

fig_11_11 Code for a task control block:

fig_11_12 Example: simple system, 3 asynchronous tasks sharing a common data buffer --get data --perform computation --display data Task queue implemented as array Will run “forever” No preemption (each task runs to completion)

fig_11_13b Kernel example

fig_11_14a Same tasks—using task control blocks

fig_11_12 Some problems with this system; Can get stuck in one task Ex: user does not input data so we are stuck in the “get” task Solution: use interrupts, break task into prompt and task to get data when it is available Shared data buffer In this example, only 1 task is active at a time so there is no conflict

fig_11_15 Typical function to set address to correct interrupt:

fig_11_17a Modification to allow interrupts Part 1 of 3):

fig_11_17b Modification to allow interrupts Part 2 of 3):

fig_11_17c Modification to allow interrupts Part 3 of 3):

fig_11_18 Registers: Can organize as multiple contexts

fig_11_19 Registers: Can organize as overlapping contexts—saves overhead on variable passing

fig_11_20 Stack: typical stack frame organization

fig_11_21 Runtime stack: multiple task information must be stored