1 / 15

Realtime System Fundamentals

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

rico
Télécharger la présentation

Realtime System Fundamentals

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. Realtime System Fundamentals B. Ramamurthy

  2. 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.

  3. 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

  4. 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

  5. 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

  6. 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)

  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

  8. 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

  9. 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); }

  10. 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); } }

  11. 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

  12. blocked task1 Critical section 0 1 2 3 4 5 6 7 8 9 10 time Priority inversion (Priority: t1>t2>t3) task2 task3

  13. 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

  14. Exercise 3.18 • We will work out exercise 3.18 to illustrate priority inheritance and priority ceiling protocol.

  15. 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

More Related