3. 互斥量的加锁和解锁必须由同一线程分别对应使用,信号量可以由一个线程释放,另一个线程得到。
互斥信号量功能:
1) 实现对资源的独占式访问(二值信号量)。
2) 降解优先级反转。
优先级反转:
使用实时内核,
优先级反转问题是实时系统中出现得最多的问题。设,任务1优先级高于任务2,任务2优先级高于任务3。任务1和任务2处于挂起状态,等待某一事件的发生,任务3正在运行如。此时,任务3要使用其共享资源。使用共享资源之前,首先必须得到该资源的信号量(Semaphore)。任务3得到了该信号量,并开始使用该共享资源。由于任务1优先级高,它等待的事件到来之后剥夺了任务3的CPU使用权,任务1开始运行。运行过程中任务1也要使用那个任务3正在使用着的资源,由于该资源的信号量还被任务3占用着,任务1只能进入挂起状态,等待任务3释放该信号量。任务3得以继续运行。由于任务2的优先级高于任务3,当任务2等待的事件发生后,任务2剥夺了任务3的CPU的使用权并开始运行。处理它该处理的事件,直到处理完之后将CPU控制权还给任3。任务3接着运行,直到释放那个共享资源的信号量。直到此时,由于实时内核知道有个高优先级的任务在等待这个信号量,内核做任务切换,使任务1得到该信号量并接着运行。
在这种情况下,
任务1优先级实际上降到了任务3 的优先级水平。因为任务1要等,直等到任务3释放占有的那个共享资源。由于任务2剥夺任务3的CPU使用权,使任务1的状况更加恶化,任务2使任务1增加了额外的延迟时间。任务1和任务2的优先级发生了反转。
纠正的方法可以是,
在任务3使用共享资源时,提升任务3的优先级。任务完成时予以恢复。任务3的优先级必须升至最高,高于允许使用该资源的任何任务。多任务内核应允许动态改变任务的优先级以避免发生优先级反转现象。然而改变任务的优先级是很花时间的。如果任务3并没有先被任务1剥夺CPU使用权,又被任务2抢走了CPU使用权,花很多时间在共享资源使用前提升任务3的优先级,然后又在资源使用后花时间恢复任务3的优先级,则无形中浪费了很多CPU时间。真正需要的是,为防止发生优先级反转,内核能自动变换任务的优先级,这叫做优先级继承(Priority inheritance)。
互斥信号量降解优先级反转的过程:
设mutex已被低优先级的任务3占用。高优先级的任务1提出申请mutex(调用Pend())。在这种情况下:
1) Pend函数注意到高优先级的任务要用这个共享资源,于是将任务3的优先级升高至9(创建mutex时指定,比任何提出申请mutex的任务的优先级都要高),并强制任务调度(由于任务3的优先级升高至9,因此任务3执行),任务3继续使用共享资源。当共享资源使用完后,任务3调用Post函数,释放mutex。
2)Post函数注意到原来占用这个mutex的任务的优先级是被太高的,于是将任务3的优先级恢复到原来水平。
3)Post还注意到有个高优先级的的任务(任务1)正在等待这个mutex,于是将mutex交给这个任务,并做任务切换,让任务1运行。
互斥信号量的组成:
一个标志,指示mutex是否可用(OS_MUTEX_AVAILABLE表示可用)。
一个优先级,即优先级继承优先级(PIP)。
一个等待mutex的任务列表。