150 likes | 260 Vues
This document outlines the progress and implementation details of various project plans in real-time systems. Key features include hardware modifications, software to generate Xinu boot images, and the availability of a cross-compiler targeting MIPS architecture. It also details real-time scheduling methods such as Earliest Deadline Scheduling and Rate Monotonic Scheduling, alongside techniques for inter-task communication utilizing mailboxes, buffers, and semaphores. A midterm exam covering these topics is scheduled, along with exercises to reinforce understanding.
E N D
Realtime System Fundamentals B. Ramamurthy
Review of Project Plans • Hardware modifications (proof of concept done) • Software to generate xinu.boot • Cross compiler (host system to MIPS) • gcc is now available at /projects/bina/NEXOS/CSE321 • We will have it installed on Linux machines at 206 Franzack • And on a Linux laptop • You can use this to compile the software you write for shell and drivers and anything else you add to exinu. • Uploading xinu.boot to test your shell and drivers: • You can do it from any system with a serial port , hyperterminal and tftp installed. Such a setup will be available in the Franzack lab and is currently available during recitation/lecture on Tuesdays at 340 Bell.
Realtime scheduling • We discussed realtime system scheduling: • Earliest deadline scheduling (EDS) • Starting deadline • Completion deadline • Dynamic priority scheduling • Rate monotonic scheduling (RMS) • Periodic tasks are prioritized by the frequency of repetition (high priority to tasks with shorter periods) • Preemptive scheduling • Fixed priority scheduling • See table 3.3 • Schedulability according to RMS Σ(Ci/Ti) <= n(21/n-1) • Cyclic executives (pre-scheduled) • Concepts of hyper-period and frame • Hyper-period is a the repeated loop • Pages 92-93 • Exercises: 3.13 – 3.17
Intertask communication and synchronization • Buffering data: • For inter-task communication • For sending data • To handle incompatibilities between tasks typically a buffer is introduced • Classical buffer (fig. 2.11) • Double buffer (fig. 2.12) • Ring buffer (fig. 2.13) • Mail boxes
Mailboxes • Mailboxes are intertask communication device available in many commercial operating systems. • A mailbox is a memory location that one or more tasks can use to pass data or for synchronization. • post and pend are used for mailbox write and read
Mailbox implementation • List of tasks and needed resources (mailboxes, printers etc.) is kept along with a second table of list of resources and their state (tables 3.6, and 3.7)
Mailbox implementation (contd) • Task 104 requests mailbox 2 “pend” or “read”; • It blocks waiting for read. • Operating system checks task table, if “key” is full or available for mailbox 2, then it unblocks Task 104 and lets it read from mailbox 2; • Task 104 reads from mailbox 2 and set it “key” back to empty. • Accept is another function for mailbox; it is a non-blocking call; it reads data if available or it fails
Task states • Ready, running and blocked • Critical regions • Semaphores for protection of critical regions • Identify the critical region and enclose it with p() and v() operators of the semaphore • Lets look at an example of implementation of mailboxes using semaphores
Mailboxes using semaphores Semaphore mutex, proc_sem; Bool full, empty; void post(int mailbox, int message) { wait(mutex); if (empty_slots){ insert(mailbox, message); update; signal(mutex); signal(proc_sem); } else {// no empty slots; wait for empty slots signal(mutex); wait(proc_sem); wait(mutex); insert(mailbox,message); update(); signal(mutex); signal(proc_sem); }
Mailboxes using semaphores void pend(int *mailbox, int *message) { wait(mutex); if (full_slots) { extract(mailbox, message); update(); signal(mutex); } else { .. signal(mutex); wait(proc_sem); wait(mutex); extract(mailbox,message); update(); signal(mutex); } }
Priority Inversion • When we allow concurrent task to execute and with semaphore and mailboxes and other synchronization primitives, it is possible that a low priority task may come to block a high priority task. This situation is known as priority inversion. • See fig.3.16
blocked task1 Critical section 0 1 2 3 4 5 6 7 8 9 10 time Priority inversion (Priority: t1>t2>t3) task2 task3
Priority Ceiling Protocol Acquire S1 Release S1 task1 Attempt to Acquire S1 Acquire S1 Acquire S2 No way task2 Acquire S2 Release S2 Critical section task3 0 1 2 3 4 5 6 7 8 9 10 time
Exercise 3.18 • We will work out exercise 3.18 to illustrate priority inheritance and priority ceiling protocol.
Midterm Exam • Chapter 3, project 1 and 2, handouts • Open book and notes • Earliest deadline scheduling • Rate monotonic scheduling • Design cyclic executive schedule given a table of task characteristics • Priority inversion and solutions in priority inheritance and priority ceiling protocols. • Projects: buffer overflow, kernel coding