Realtime System Fundamentals

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/CSE32
  1
• 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
• S(Ci/Ti) lt 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)

taskID Resource Status
100 printer Has it
102 Mailbox 1 Has it
104 Mailbox 2 pending
resource status owner
printer busy 100
Mailbox 1 busy 102
Mailbox 2 empty none
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
  taks may come to block a high priority task. This
  situation is known as priority inversion.
• See fig.3.16