1 / 31

ECT 358

ECT 358. Lecture 27 Real Time Operating Systems. Aurthority makes some people grow – and others just swell. But he that is greatest among you shall be your servant. And whosoever shall exalt himself shall be abased; and he that shall humble himself shall be exalted. Matthew 23:11-2.

hada
Download Presentation

ECT 358

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ECT 358 Lecture 27 Real Time Operating Systems

  2. Aurthority makes some people grow – and others just swell. But he that is greatest among you shall be your servant. And whosoever shall exalt himself shall be abased; and he that shall humble himself shall be exalted. Matthew 23:11-2

  3. Real-Time Operating System (RTOS) • Provides standard set of services to help manage task execution • Avoids many of the problems of applying foreground/background to a`periodic systems

  4. RTOS Program Structure

  5. Some Definitions • Critical Section of Code • Code which must not be interrupted • Typically disable interrupts while it is executing • Task • Simple program which thinks it is executing alone in the CPS • Can be considered a thread • Each task has a priority, its own set of registers, and its own stack area • Resource • Any entity used by a task (I/O device, variable, array, memory, etc) • Shared Resource • Resource that can be used by more than one task • Task should gain exclusive use of the resource to prevent data corruption • Exclusive use is called mutual exclusion

  6. Some Definitions (cont) • Multitasking • Process of scheduling and switching the CPU among several tasks • Only one task is running at any given time instant although many may be “executing” • The OS task switching mechanism allows each task to have the illusion that it has the CPU to itself • May also be considered multithreading • Task States • Task is typically an infinite loop than can be in any of five states • Dormant • Residing in memory but not available to the OS • Ready • Task is ready to execute but has a lower priority than the currently running task • Running • Task has control of the CPU • Waiting • Task requires the occurrence of an event (I/O operation to complete, shared resource available, etc.) • Interrupted • The task was running and an interrupt occurred—CPU is servicing the interrupt

  7. Some Definitions (cont) • Context • Current Task’s CPU registers • Context Switch • Saving one task’s context and restoring another’s

  8. Multiple Tasks

  9. Task States

  10. Kernel • Responsible for task management and inter-task communication • Kernel provides services to support context switching • Requires extra code space, additional data space, and additional task space • Requires additional CPU time

  11. Scheduler (Dispatcher) • Responsible for determining which task will run next • Since most R-T Kernels are priority based, this is priority scheduler • Control of CPU is given to highest priority task that is ready to run • When task gets control of CPU is dependent upon type of Kernel used • Non-preemptive • Preemptive

  12. Non-Preemptive Kernel • Requires task to explicitly give up control of the CPU • To maintain illusion of concurrency, this process must be done frequently • A`periodic tasks handled by ISR • ISR may make higher priority task ready to run but ISR always returns to interrupted task • Higher priority task gains control of CPU only when the current task relinquishes it

  13. Preemptive Kernel • Highest priority task ready to run is always given control of the CPU • When a task makes a higher priority task ready to run, current task is preempted (suspended) and higher priority task given control of CPU • If ISR makes higher priority task ready, when ISR completes, the interrupted task is suspended and the higher priority task runs

  14. Reentrancy • Reentrant Functions • A reentrant function may be used by more than one task without fear of data corruption • May be interrupted at any time and resumed later without loss of data • May use local or global variables • If using global variables, function must protect global data • Place arguments on task stack to preserve • Non-Reentrant Functions • Cannot guarantee integrity of data in multitasking system

  15. Task Priority • Assigned to each task • Higher priorities given to most important tasks • Priority may be static or dynamic • Static Priority • Assigned at compile time • Doesn’t change during execution • Dynamic Priority • Assigned at run time • May be changed during run

  16. Assigning Task Priorities • Alternatives • Static or fixed priority • Similar to what we did in the foreground/background approach (highest rate first) • Rate-Monotonic Algorithm • Highest Rate is given highest priority • Assumptions • Periodic tasks • Tasks do not synchronize with each other, share resources or exchange data • Preemptive scheduling must be used • RMS Theorem • Given n tasks, all task hard real-time deadlines will always be met if • (Ei/Ti) < n(21/n –1) , where Ei is maximum execution time of the task Ti is the execution period

  17. RMS Theorem (cont) • If CPU utilization is less than 70% for all time critical tasks, we can meet all the required deadlines. • For design, a better approach is to design critical task load to use a maximum of approximately 50% of the CPU • This leaves some room the non-critical tasks and growth

  18. Mutual Exclusion • Shared data structures provide easiest inter task communication scheme • Simplifies exchange of information • Must ensure each task exclusive access to data to avoid contention and corruption • Exclusive access methods • Disabling interrupts • Test and set operations • Disabling scheduling • Semaphores

  19. Disabling and Enabling Interrupts • Shared resource access example pseudo code Disable interrupts; Access the resource (read/write from/to variables); Reenable interrupts; • OS may provide macros to support disabling and enabling interrupts • For Example, uC/OS-II macros • OS_ENTER_CRITICAL() • OS_EXIT_CRITICAL() • Caution: disabling interrupts for too long affects interrupt latency of system

  20. Test-And-Set (TAS) • Define a global variable to be checked • To access a resource, function tests the global variable • If zero, function sets variable to one and begins using resource • If one, function knows the resource is in use and must wait to access it • Function using resource must clear the global variable when finished with the resource

  21. Disabling and Enabling the Scheduler • Temporarily creates a non-preemptive situation • Interrupts are enabled but always return to the interrupted task independent of priority • Method works but probably should avoid • Defeats purpose of having a scheduler and a kernel

  22. Semaphores • Used to • Control access to a shared resource (mutual exclusion) • Signal occurrence of an event • Allow two tasks to synchronize activities • Think of semaphore as a key that the code acquires in order to continue execution

  23. Semaphores • Invented the Edgser Dijkstra in the 1960’s • Use to • control access to a shared resource (mutual exclusion) • signal the occurrence of an event • allow two tasks to synchronize their activities

  24. Accessing Peripherals with Semaphores • Use binary semaphore

  25. Buffer Management Using Semaphores • Counting Semaphore • Use when resource can be used by more than one task at same time • Example—10 buffers • Buffer manager satisfies first 10 buffer requests directly • When all semaphores used, task requesting buffer is suspended until semaphore available

  26. Deadlocks and Semaphores • Situation where two tasks are waiting for resource held by the other • E.g. Task 1 has exclusive use of resource R1 and Task 2 has exclusive use of resource R2. • T1 requires exclusive use of R2 and T2 requires exclusive use of R1 • Neither task can complete • Avoid by • Acquire all resources before beginning • Acquire resources in same order • Release resource in reverse order • If kernel allows a timeout to be specified with semaphore (uC/OS-II does), this allows deadlock to be broken • Deadlocks generally occur in large, multi-tasking systems

  27. Task Synchronization • Semaphores • Event Flags

  28. Synchronization • Synchronize tasks with a semaphore • Will work with ISR or another task

  29. Event Flags • Used to synchronize task with multiple event occurrence • Synchronize when any of the events have occurred • disjunctive synchronization • effectively the logical OR of event occurrence

  30. Event Flags (Cont) • Synchronize when all of the events have occurred • conjunctive synchronization • effectively the logical AND of event occurrence

  31. Multiple Task Signaling • Common events may signal multiple tasks

More Related