Realtime System Fundamentals B. Ramamurthy 5/28/2016 Page 1

advertisement
Realtime System Fundamentals
B. Ramamurthy
Page 1
5/28/2016
Review of Project Plans
•
•
–
Hardware modifications
Software to generate xinu.boot
Cross compiler (host system to MIPS)
1.
2.
–
•
–
Fronzak 206 is ready for use
David will provide you instructions to access the NEXOS setup
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:
–
Page 2
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.
This will be available for remote access from next week
5/28/2016
Realtime scheduling
•
We will discuss 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
• Schedulability according to RMS
Σ(Ci/Ti) <= n(21/n-1)
– Cyclic executives (pre-scheduled)
• Concepts of cycle, slot and frame
• Repeated execution
• times
Page 3
5/28/2016
Critical sections and Semaphores
• When multiples tasks are executing there
may be sections where only one task could
execute at a given time: critical region or
critical section
• There may be resources which can be
accessed only be one of the processes:
critical resource
• Semaphores can be used to ensure mutual
exclusion to critical sections and critical
resources
Page 4
5/28/2016
Semaphores
See semaphore.h of xinu
Page 5
5/28/2016
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.
Page 6
5/28/2016
Priority inversion
(Priority: t1>t2>t3)
blocked
task1
task2
Critical
section
task3
0
1
Page 7
2
3
4
5
6
7
8
time
9
10
5/28/2016
Priority Ceiling Protocol
Acquire S1
CS
Used
by
Priority
Ceiling
S1
t1,t2
P(t1)
S2
t1,t2,t3
P(t1)
S3
t3
P(t3)
Release S1
task1
Attempt to
Acquire S1
No way
task2
Acquire S1
Acquire S2
Release S2
Critical
section
task3
0
1
Page 8
2
Acquire S2
3
4
5
6
7
8
time
9
10
5/28/2016
Inter-task communication and
synchronization
• Buffering data:
– For inter-task communication
– For sending data
– To handle incompatibilities between tasks typically
a buffer is introduced
• Classical buffer
• Double buffer
• Ring buffer
• Mail boxes
Page 9
5/28/2016
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
Page 10
5/28/2016
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
Page 11
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
5/28/2016
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 nonblocking call; it reads data if available or it fails
Page 12
5/28/2016
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
Page 13
5/28/2016
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);
}
Page 14
5/28/2016
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); }
}
Page 15
5/28/2016
Download