1 / 24

Real Time Operating Systems

Real Time Operating Systems. Mutual Exclusion, Synchronization & Intertask Communication Course originally developed by Maj Ron Smith. Outline. Mutual Exclusion, Synchronization & Intertask Communications Semaphores Message Mailboxes & Queues Event Flags Task Dependency Issues

kent
Télécharger la présentation

Real Time Operating Systems

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. Real Time Operating Systems Mutual Exclusion, Synchronization & Intertask Communication Course originally developed by Maj Ron Smith

  2. Outline • Mutual Exclusion, Synchronization & Intertask Communications • Semaphores • Message Mailboxes & Queues • Event Flags • Task Dependency Issues • Priority Inversion • Priority Inheritance / Ceiling Priority Protocols • Mutual Exclusion Semaphores Dr Alain Beaulieu

  3. Mutual Exclusion • Recall that in a preemptive system, shared resources, including data stores, must often be protected by mutual exclusion • Further recall the following techniques to address mutual exclusion in μC/OS: • disabling/enabling interrupts • disabling scheduling • using semaphores Exactly what seemingly simple problem does the semaphore solve? Dr Alain Beaulieu

  4. Task Synchronization • Dependence between tasks is not always a “data” dependency (shared resource) • It is also possible that tasks are temporally dependent, meaning that the execution, or continued execution, of one task depends upon the completion, or partial completion, of another task(s) • Recall that this type of dependency is often modeled as a rendezvous • unilateral, bilateral, … Dr Alain Beaulieu

  5. Intertask Communication • One way in which tasks can communicate with each other is through shared data stores • This introduces the mutual exclusion problem discussed previously • An alternate method is for tasks to send each other messages • often modeled as mailboxes and queues Does messaging remove the intertask dependency? Dr Alain Beaulieu

  6. Semaphores OSSemCreate( ) OSSemDel( ) OSSemPost( ) OSSemAccept( ) OSSemPend( ) OSSemQuery( ) Task Task or ISR ISR OSSemPost( ) OSSemAccept( ) Used for mutual exclusion or synchronization Dr Alain Beaulieu

  7. Message Mailbox OSMboxCreate( ) OSMboxDel( ) OSMboxPost( ) OSMboxPostOpt( ) OSMboxAccept( ) OSMboxPend( ) OSMboxQuery( ) Task Task ISR ISR OSMboxPost( ) OSMboxPostOpt( ) OSMboxAccept( ) Message Dr Alain Beaulieu

  8. Message Queues OSQCreate( ) OSQDel( ) OSQFlush OSQPost( )/PostFront( ) OSQPostOpt( ) OSQAccept( ) OSQPend( ) OSQQuery( ) Task Task ISR ISR OSQFlush OSQPost( )/PostFront( ) OSQPostOpt( ) OSQAccept( ) Message Dr Alain Beaulieu

  9. *See example in handout Event Flags* OSFlagCreate( ) OSFlagDel( ) OSFlagPost( ) OSFlagAccept( ) OSFlagPend( ) OSFlagQuery( ) Task Task ISR ISR OSFlagPost( ) OSFlagAccept( ) OSFlagQuery( ) Event Flag Group Dr Alain Beaulieu

  10. Task Independence • The assumption that tasks are independent is unreasonable for any meaningful system • tasks share common resources via semaphores • tasks often must synchronize with each other • tasks often must communicate with each other • This implies that a task(s) may suspend pending some future event which is dependent upon one or more other tasks How will this dependence affect task execution on a priority-based preemptive kernel? Dr Alain Beaulieu

  11. Priority Inversion • Priority inversion • can occur when a high and a low priority task share a common resource • the low priority task gets exclusive access to the shared resource • the higher priority task preempts the lower priority task but is blocked pending release of the shared resource • meanwhile a medium priority task preempts the lower priority task, thus further delaying the execution of the high priority task • since the medium task is guaranteed priority service over the blocked higher priority task, we get priority inversion Dr Alain Beaulieu

  12. Illustrated Priority Inversion medium high low (1) (2) (3) (4) (5) (6) (7) (8) Time (9) (10) (11) low priority task locks shared resource high priority task blocks pending release of shared resource medium priority task preempts low (and high) priority tasks Dr Alain Beaulieu

  13. Priority Inheritance • Simple priority inheritance is a technique for avoiding priority inversion • the priority of a task gaining access to a shared resource dynamically inherits the priority of the highest priority task sharing the resource • inheritance occurs when the blocking event occurs • Theorem : if priority inheritance is employed, the number of times a task can be blocked by lower priority tasks is limited by the lessor of: • K - the number of blocking critical sections; or • N - the number of lower priority tasks Dr Alain Beaulieu

  14. Transitive Blocking • Using simple priority inheritance to handle the priority inversion problem, can result in tasks being transitively blocked by multiple other tasks • Transitive blocking means that a series of blocking events occur wherein lower priority tasks block, in succession, block higher priority tasks Although the probability of these transitive events is very low, it is possible in the worst-case! Dr Alain Beaulieu

  15. Illustrated Transitive Blocking • The graph below illustrates transitive priority inheritance among 3 tasks & 2 resources L(R1) U(R1) T1 =1 =1 L(R1) L(R2) U(R2) U(R1) T2 =2 =1 =1 =2 =2 L(R2) U(R2) T3 =3 =3 =1 =3 10 0 2 4 6 8 Dr Alain Beaulieu

  16. Deadlock • Another serious issue that arises with shared resources is deadlock • While the use of a simple priority inheritance algorithm addresses priority inversion, it does not help prevent deadlock Think about how deadly deadlock might be to a real-time system! Dr Alain Beaulieu

  17. Illustrated Deadlock • Given: T= {(3.5, 1; R1(0.2), R2(0.7)), (4,1), (5, 2, 7; R1(0.8),R2(0.1)) } L(R2) L(R1) - requests R1 & blocks T1 T2 L(R1) L(R2) - requests R2 & blocks - forever, T1 now blocks forever as well T3 10 0 2 4 6 8 Dr Alain Beaulieu

  18. Yet another view of deadlock • From this “wait-for” graph, we see that the closed loop is also evidence of a deadlock R1 T1 T2 R2 Dr Alain Beaulieu

  19. Ceiling Priority Protocols • A class of resource sharing algorithms entitled Ceiling Priority Protocols are introduced as an alternative to simple priority inheritance to: • eliminate transitive blocking • for any given task only a single blocking event may occur • eliminate deadlock • a task holding one resource may not claim another resource that could lead to circular lock/requests Dr Alain Beaulieu

  20. Original Ceiling Priority Protocol • Each task has a static default priority • Each resource has a static ceiling value, equal to the maximum priority of the processes which use it • Each task has a dynamic priority, equal to the maximum of its own static priority and any it inherits from ceiling(s) due to blocking higher priority tasks • A task can lock a resource only if its dynamic priority is higher than the ceiling of any currently locked resource (excluding of course any it has locked) Dr Alain Beaulieu

  21. Immediate Ceiling Priority Protocol • Each task has a static default priority assigned (using some priority assignment - maybe DMPO) • Each resource has a static ceiling value, equal to the maximum priority of the processes which use it • Each task also has a dynamic priority, equal to the maximum of its own static priority and the ceiling values of any resources it has locked • inheritance happens immediately upon locking the resource Dr Alain Beaulieu

  22. *See example in handout Mutual Exclusion Semaphores • When a task requests a OSMutexPend( ) on a mutex that is currently held by a lower priority task, the system call raises the priority of the lower priority task to that of the mutex, thus causing a context switch. Similarly when this task releases the mutex with the OSMutexPost( ), this system call restores the priority of the lower priority task, and … OSMutexAccept( ) OSMutexPend( ) OSMutexQuery( ) OSMutexCreate( ) OSMutexDel( ) OSMutexPost( ) Task Task Note how μC/OS’ unique priority assignment constrains the use of mutexes. Dr Alain Beaulieu

  23. Questions • Is the μC/OS Mutual Exclusion Semaphore (Mutex) an implementation of simple priority inheritance, or immediate ceiling priority protocol? • What are the implications of your answer? Dr Alain Beaulieu

  24. References [1] Liu, J.W.S., “Real-Time Systems”, Prentice-Hall, 2000. [2] Labrosse, J.J., “MicroC/OS-II” 1st and 2nd Editions (1999, 2002) [3] Burns, A. and Wellings, A., “Real-Time Systems and Programming Languages”, Chapter 13, Addison Wesley, 1997 Dr Alain Beaulieu

More Related