Realtime System Fundamentals : Scheduling and Priority-based scheduling B. Ramamurthy 11/22/2018.

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

Chapter 7 - Resource Access Protocols (Critical Sections) Protocols: No Preemptions During Critical Sections Once a job enters a critical section, it cannot.
1 EE5900 Advanced Embedded System For Smart Infrastructure RMS and EDF Scheduling.
B. RAMAMURTHY 4/13/2015 cse321-fall2014 Realtime System Fundamentals : Scheduling and Priority-based scheduling Pag e 1.
Resource management and Synchronization Akos Ledeczi EECE 354, Fall 2010 Vanderbilt University.
0 Synchronization Problem Resource sharing –Requires mutual exclusion –Critical section A code section that should be executed mutually exclusively by.
CprE 458/558: Real-Time Systems (G. Manimaran)1 CprE 458/558: Real-Time Systems Resource Access Control Protocols.
A Simple Critical Section Protocol There are N concurrent processes P 1,…,P N that share some data. A process accessing the shared data is said to execute.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Semaphores and Mailboxes B. Ramamurthy 1. Page 2 Critical sections and Semaphores When multiples tasks are executing there may be sections where only.
Semaphores CSCI 444/544 Operating Systems Fall 2008.
Computer Science 162 Discussion Section Week 3. Agenda Project 1 released! Locks, Semaphores, and condition variables Producer-consumer – Example (locks,
Embedded Xinu Kernel Programming
LAB 11: Task Synchronization Chung-Ta King National Tsing Hua University CS 4101 Introduction to Embedded Systems.
Midterm 1 – Wednesday, June 4  Chapters 1-3: understand material as it relates to concepts covered  Chapter 4 - Processes: 4.1 Process Concept 4.2 Process.
Real-Time Scheduling CS4730 Fall 2010 Dr. José M. Garrido Department of Computer Science and Information Systems Kennesaw State University.
Page 1 Task Control: Signals and Alarms Chapter 7 and 8 B. Ramamurthy.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts Essentials – 9 th Edition Chapter 5: Process Synchronization.
Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution.
B. RAMAMURTHY 12/25/2015 Realtime System Fundamentals : Scheduling and Priority-based scheduling Pag e 1.
Introduction to Embedded Systems Rabie A. Ramadan 5.
CS 2200 Presentation 18b MUTEX. Questions? Our Road Map Processor Networking Parallel Systems I/O Subsystem Memory Hierarchy.
3/1/2016Page 1 Realtime System Fundamentals : Scheduling B. Ramamurthy.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Big Picture Lab 4 Operating Systems C Andras Moritz
Chapter 6 Synchronization Dr. Yingwu Zhu. The Problem with Concurrent Execution Concurrent processes (& threads) often access shared data and resources.
6.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Synchronization Background The Critical-Section Problem Peterson’s.
Real-Time Threads Time dependent, usually wrt deadline –Periodic –Aperiodic –Sporadic Priority scheduled Fault tolerant.
6.1 Silberschatz, Galvin and Gagne ©2005 Operating System Principles 6.5 Semaphore Less complicated than the hardware-based solutions Semaphore S – integer.
Deadlock and Starvation
CS703 – Advanced Operating Systems
Semaphore Synchronization tool that provides more sophisticated ways (than Mutex locks) for process to synchronize their activities. Semaphore S – integer.
COT 4600 Operating Systems Fall 2009
Chapter 5: Process Synchronization
PARALLEL PROGRAM CHALLENGES
Chapter 5: Process Synchronization – Part II
Chapter 5: Process Synchronization
EEE 6494 Embedded Systems Design
IS310 Hardware & Network Infrastructure Ronny L
Chapter 5: Process Synchronization
Xinu Semaphores.
Realtime System Fundamentals : Scheduling and Priority-based scheduling B. Ramamurthy cse321-fall2014 9/20/2018.
תרגול 4 – ניהול תהליכים, מבני נתונים למימוש תהליכים
Xinu Semaphores.
Chapter 6: Synchronization Tools
Realtime System Fundamentals : Scheduling and Priority-based scheduling B. Ramamurthy cse321-fall /27/2018.
Topic 6 (Textbook - Chapter 5) Process Synchronization
Semaphore Originally called P() and V() wait (S) { while S <= 0
Today’s agenda Lab 1 Module 4: Process Management
Realtime System Fundamentals
Lecture 2 Part 2 Process Synchronization
Chapter 7: Synchronization Examples
Realtime System Fundamentals
Realtime System Fundamentals : Scheduling and Priority-based scheduling B. Ramamurthy Amrita-UB-MSES /11/2013.
Xinu Semaphores.
Synchronization Primitives – Semaphore and Mutex
Realtime System Fundamentals
Chapter 6: Synchronization Tools
CSE 153 Design of Operating Systems Winter 19
CSE 153 Design of Operating Systems Winter 2019
Chapter 6: Synchronization Tools
Real-Time Process Scheduling Concepts, Design and Implementations
Real-Time Process Scheduling Concepts, Design and Implementations
Chapter 3: Process Management
Lab #9 Semaphores Operating System Lab.
Presentation transcript:

Realtime System Fundamentals : Scheduling and Priority-based scheduling B. Ramamurthy 11/22/2018

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 Schedulability according to RMS Σ(Ci/Ti) <= n(21/n-1) Cyclic executives (pre-scheduled) (later: next class?) Concepts of cycle, slot and frame Repeated execution times 11/22/2018

Task State Diagram New Ready Blocked Run 11/22/2018 Task admitted Resources allocated Dispatched; cpu allocated Event occurred Task exit Blocked Run Waiting for event 11/22/2018

Resources & Critical Resources Shared resources: need mutual exclusion Tasks cooperating to complete a job Tasks contending to access a resource Tasks synchronizing Critical resources and critical region A important synchronization and mutual exclusion primitive / resource is “semaphore” 11/22/2018

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 11/22/2018

Semaphores See semaphore.h of xinu 11/22/2018

Semaphores in exinu #include <kernel.h> #include <queue.h> /**< queue.h must define # of sem queues */ /* Semaphore state definitions */ #define SFREE 0x01 /**< this semaphore is free */ #define SUSED 0x02 /**< this semaphore is used */ /* type definition of "semaphore" */ typedef ulong semaphore; /* Semaphore table entry */ struct sentry { char state; /**< the state SFREE or SUSED */ short count; /**< count for this semaphore */ queue queue; /**< requires q.h. */ };

Semaphores in exinu (contd.) extern struct sentry semtab[]; /** * isbadsem - check validity of reqested semaphore id and state * @param s id number to test; NSEM is declared to be 100 in kernel.h A system typically has a predetermined limited number of semaphores */ #define isbadsem(s) (((ushort)(s) >= NSEM) || (SFREE == semtab[s].state)) /* Semaphore function declarations */ syscall wait(semaphore); syscall signal(semaphore); syscall signaln(semaphore, short); semaphore newsem(short); syscall freesem(semaphore); syscall scount(semaphore);

Definition of Semaphores functions static semaphore allocsem(void); /** * newsem - allocate and initialize a new semaphore. * @param count - number of resources available without waiting. * example: count = 1 for mutual exclusion lock * @return new semaphore id on success, SYSERR on failure */ semaphore newsem(short count) { irqmask ps; semaphore sem; ps = disable(); /* disable interrupts */ sem = allocsem(); /* request new semaphore */ if ( sem != SYSERR && count >= 0 ) /* safety check */ semtab[sem].count = count; /* initialize count */ restore(ps); /* restore interrupts */ return sem; /* return semaphore id */ } restore(ps);

Semaphore: newsem contd. /** * allocsem - allocate an unused semaphore and return its index. * Scan the global semaphore table for a free entry, mark the entry * used, and return the new semaphore * @return available semaphore id on success, SYSERR on failure */ static semaphore allocsem(void) { int i = 0; while(i < NSEM) /* loop through semaphore table */ { /* to find SFREE semaphore */ if( semtab[i].state == SFREE ) semtab[i].state = SUSED; return i; } i++; return SYSERR; }

Semaphore: wait(…) /** * wait - make current process wait on a semaphore * @param sem semaphore for which to wait * @return OK on success, SYSERR on failure */ syscall wait(semaphore sem) { irqmask ps; struct sentry *psem; pcb *ppcb; ps = disable(); /* disable interrupts */ if ( isbadsem(sem) ) /* safety check */ restore(ps); return SYSERR; } ppcb = &proctab[currpid]; /* retrieve pcb from process table */ psem = &semtab[sem]; /* retrieve semaphore entry */ if( --(psem->count) < 0 ) /* if requested resource is unavailable */ ppcb->state = PRWAIT; /* set process state to PRWAIT*/

Semaphore: wait() ppcb->sem = sem; /* record semaphore id in pcb */ enqueue(currpid, psem->queue); resched(); /* place in wait queue and reschedule */ } restore(ps); /* restore interrupts */ return OK;

Semaphore: signal() /*signal - signal a semaphore, releasing one waiting process, and block * @param sem id of semaphore to signal * @return OK on success, SYSERR on failure */ syscall signal(semaphore sem) { irqmask ps; register struct sentry *psem; ps = disable(); /* disable interrupts */ if ( isbadsem(sem) ) /* safety check */ restore(ps); return SYSERR; } psem = &semtab[sem]; /* retrieve semaphore entry */ if ( (psem->count++) < 0 ) /* release one process from wait queue */ { ready(dequeue(psem->queue), RESCHED_YES); } restore(ps); /* restore interrupts */ return OK;

Semaphore: usage Problem 1: Create 3 tasks that each sleep for a random time and update a counter. Counter is the critical resources shared among the processes. Only one task can update the counter at a time so that counter value is correct. Problem 2: Create 3 tasks; task 1 updates the counter by 1 and then signal task 2 that updates the counter by 2 and then signals task 3 to update the counter by 3.

Problem 1 #include <..> //declare semaphore semaphore mutex1 = newsem(1); int counter = 0; //declare functions: proc1,proc1, proc3 ready(create((void *)proc1, INITSTK, INITPRIO, “PROC1",, 2, 0, NULL), RESCHED_NO); ready(create((void *)proc2, INITSTK, INITPRIO, “PROC2",, 2, 0, NULL), RESCHED_NO); ready(create((void *)proc3, INITSTK, INITPRIO, “PROC3",, 2, 0, NULL), RESCHED_NO);

Problem 1: multi-tasks void proc1() { while (1) { sleep (rand()%10); wait(mutex1); counter++; signal(mutex1); } } void proc2() //similarly proc3

Problem 1 Task 1 Task 2 Counter1 Task 3

Problem 2 semaphore synch12 = newsem(0); semaphore synch23 = newsem(0); semaphore synch31 = newsem(0); ready(create((void *)proc1, INITSTK, INITPRIO, “PROC1",, 2, 0, NULL), RESCHED_NO); ready(create((void *)proc2, INITSTK, INITPRIO, “PROC2",, 2, 0, NULL), RESCHED_NO); ready(create((void *)proc3, INITSTK, INITPRIO, “PROC3",, 2, 0, NULL), RESCHED_NO); signal(synch31);

Task flow void proc1() void proc2() void proc3() { while (1) { sleep (rand()%10); wait(synch31); counter++; signal(synch12); } } void proc2() wait(synch12); signal(synch23); void proc3() sleep(rand()%10); wait(synch23); signal(synch31); } }

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. 11/22/2018

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

Problem: Priority inversion Solution1: Priority Inheritance task1 blocked Task 2 delayed task2 Priority of t1 inherited Critical section Priority reverted To t3 task3 0 1 2 3 4 5 6 7 8 9 10 time 11/22/2018

Solution2:Priority Ceiling Protocol CS Used by Priority Ceiling S1 t1,t2 P(t1) S2 t1,t2,t3 S3 t3 P(t3) 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 11/22/2018