Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
The concept of operating systems and their goals. It also discusses the components of a computer system and the abstract view of system components. The document further explains RT extensions and how to do an RT extension. It also discusses component-based kernels and admission control.
Typology: Lecture notes
1 / 23
This page cannot be seen from the preview
Don't miss anything!
1
Sebastian Fischmeister CSE480/CIS700 S.^ Fischmeister^2
A program that acts as an intermediary between a user of a computer and the computer hardware Operating system goals: o Execute user programs and make solving user problems easier. o Make the computer system convenient to use Use the computer hardware in an efficient manner
CSE480/CIS700 S.^ Fischmeister^3
CSE480/CIS700 S.^ Fischmeister^7
Small, fast, proprietary kernels RT extensions to commercial timesharing systems Component-based kernels University-based kernels CSE480/CIS700 S.^ Fischmeister^8
They come in two varieties: o Homegrown o Commercial offerings Usually used for small embedded systems Typically specialized for one particular application Typically stripped down and optimized versions: o Fast context switch o Small size, limited functionality o Low interrupt latency o Fixed or variable sized partitions for memory management PICOS18, pSOS, MicroC, …
CSE480/CIS700 S.^ Fischmeister^9
A common approach is to extend Unix o Linux: RT-Linux, RTLinuxPro, RTAI, o Posix: RT-Posix o MACH: RT-MACH Also done for Windows based on virtualization. Generally slower and less predictable. Richer environment, more functionality. These systems use familiar interfaces, even standards. Problems when converting an OS to an RTOS: o Interface problems (nice and setpriority in Linux) o Timers too coarse o Memory management has no bounded execution time o Intolerable overhead, excessive latency CSE480/CIS700 S.^ Fischmeister^10
Compliant kernels o Takes an existing RTOS and make it execute other UNIX binaries (see LynxOS). o Interfaces need to be reprogrammed. o Behavior needs to be correctly reimplemented.
CSE480/CIS700 S.^ Fischmeister^13
The source consists of a number of components that can be selectively included to compose the RTOS. See OS-Kit, Coyote, PURE, 2k, MMLite, Pebble, Chaos, eCos. eCos o Hardware Abstraction Layer (HAL) o Real-time kernel Interrupt handling Exception handling Choice of schedulers Thread support Rich set of synchronization primitives Timers, counters and alarms Choice of memory allocators Debug and instrumentation support Counters -- Count event occurrences Clocks -- Provide system clocks Alarms -- Run an alarm function Mutexes Condition Variables -- Synchronization primitive -- Synchronization primitive Semaphores -- Synchronization primitive Mail boxes -- Synchronization primitive Event Flags -- Synchronization primitive Spinlocks -- Low-level Synchronization Primitive Scheduler Control -- Control the state of the scheduler Interrupt Handling -- Manage interrupt handlers CSE480/CIS700 S.^ Fischmeister^14
eCos o μITRON 3.0 compatible API o POSIX compatible API o ISO C and math libraries o Serial, ethernet, wallclock and watchdog device drivers o USB slave support o TCP/IP networking stacks o GDB debug support All components can be added through a configuration file that includes and excludes parts of the source code.
CSE480/CIS700 S.^ Fischmeister^15
Many researchers built a new kernel for one of these reasons: o Challenge basic assumptions made in timesharing OS o Developing real-time process models o Developing real-time synchronization primitives o Developing solutions facilitating timing analysis o Strong emphasis on predictability o Strong emphasis on fault tolerance o Investigate the object-oriented approach o Real-time multiprocessor support o Investigating QoS 16
CSE480/CIS700 S.^ Fischmeister^19
Admission control is a function that decides if new work entering the system should be admitted or not. To perform this it requires: o A model of the state of system resources o Knowledge about incoming requests o An algorithm to make the admission decision o Policies for actions to take upon admission and rejection Statically scheduled systems require no admission control. CSE480/CIS700 S.^ Fischmeister^20
The admission algorithm requires preanalyzed tasks Shared data Execution time Precedence information Importance level Deadlines Positive decision assigns time slices to the task Negative decision has options: o Run a simpler version of the task o Run on a different machine o Reject the task Admission algorithms can be complex as they have to consider multiple resources (e.g., networked video streaming).
CSE480/CIS700 S.^ Fischmeister^21
Resource reservation is the act of actually assigning resources to a task. o Initially no resource reservation, only allocation as the task runs. o Valuable for hard real-time systems. o Introduces an overhead as resources might be unused => introduction of resource reclaiming strategies Closely linked to resource kernels that offer interfaces for resource reservation, donation, and reflection. CSE480/CIS700 S.^ Fischmeister^22
RTOSs tailored to microprocessors often require a static declaration of tasks. Advantages are: o Simple check that the system has sufficient resources. o No admission control necessary. o No overhead introduced by the admission test. o No thread spawning problems => but quite static
CSE480/CIS700 S.^ Fischmeister^25
Remove unused functions o May be done via linker automatically Replace functionality o Motor placement comes in three functions: Calculated Lookup table (program memory) Lookup table (EEPROM) Conditional compilation o Use #if, #ifdef constructs o Needs configuration editor o Example: Linux make config…. CSE480/CIS700 S.^ Fischmeister^26
Per (boolean) configuration option, we obtain two new OS versions. Embedded systems require extensive testing. The application must be tested with each configuration separately: o 100 configuration options we get around 2^ o Require hardware setup o Require software setup o Require reporting for automated testing
CSE480/CIS700 S.^ Fischmeister^27
I/O normally only through kernel via an system call. o Expensive but provides control In an RTOS for embedded systems, tasks are allowed to do I/O operations directly o Direct fast access o Direct task to task communication between chips Problem: Can cause troubles if tasks interfere Solution: Programmer must do synchronization too CSE480/CIS700 S.^ Fischmeister^28
Normal OS: Interrupts are kernel only o Must be reliable (dropped disk interrupts…) o Costly: Notification via context switch/syscalls Embedded OS: tasks can use interrupts o Again: only trusted/tested programs o Speed important o Fast task control possible o But: modularity decreases, as tasks may have to share interrupts correctly
CSE480/CIS700 S.^ Fischmeister^31
Task, also called thread, is a user application. o Shares the CPU and resources with other tasks o Follows a defined life cycle CSE480/CIS700 S.^ Fischmeister^32
A context switch occurs whenever the multitasking kernel decides to run a different task. o Save the current task’s context in the storage area. o Restores the new task’s context from the storage area. o Resumes the new task Context switching adds overhead. The more registers a processor has, the higher the overhead => irrelevant for RTOS as long as its known.
CSE480/CIS700 S.^ Fischmeister^33
The kernel is responsible for managing the tasks. Most fundamental service is the context switch. Non-preemtive kernels, also cooperative multitasking o The task needs to explicitly give up control of the CPU. o Allows low interrupt latency, because they may be never disabled. o Allows non-reentrant functions at the task level. o Response time is determined by the longest task. o No overhead for protecting shared data. o Responsiveness may be low, because of low priority task requiring a lot of time until it releases the CPU. CSE480/CIS700 S.^ Fischmeister^34
Preemptive kernel o Responsiveness is good, because tasks get preempted. o A higher-priority task can preempt a lower priority task that still requires more time to compute. o Response time becomes deterministic, because at the next tick, the OS switches to the other new task. o Non-reentrant functions require careful programming. o Periodic execution of the ‘tick’ adds to the overhead.
CSE480/CIS700 S.^ Fischmeister^37
Part of the user application. One for the high priority interrupts and one for low priority interrupts. Most important part: AddOneTick() Let’s have a look. CSE480/CIS700 S.^ Fischmeister^38
The active task gets suspended and its context gets pushed onto its stack. The preempted task gets resumed and its context gets restored. Let’s have look at the save_task_ctx routine.
CSE480/CIS700 S.^ Fischmeister^39
PICOS18 requires you to statically declare o Alarms o Resources o Tasks Let’s have a look. CSE480/CIS700 S.^ Fischmeister^40
StatusType ActivateTask (TaskType TaskID) o Change the state of a task from SUSPENDED to READY. StatusType TerminateTask (void) o Changes the state of a task from READY to SUSPENDED. StatusType ChainTask (TaskType TaskID) o Terminates the current task, activates a follow up task. StatusType Schedule(void) o Invoke the scheduler to find a new active task. o Not necessary, because PICOS18 is a preemptive OS. StatusType GetTaskID (TaskRefType TaskID) StatusType GetTaskState (TaskType TaskID, TaskStateRefType State)
