理解互斥信号量
2012-04-20 10:52
141 查看
互斥量和信号量的区别
1. 互斥量用于线程的互斥,信号线用于线程的同步。
这是互斥量和信号量的根本区别,也就是互斥和同步之间的区别。
互斥:是指某一资源同时只允许一个访问者对其进行访问,具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序,即访问是无序的。
同步:是指在互斥的基础上(大多数情况),通过其它机制实现访问者对资源的有序访问。在大多数情况下,同步已经实现了互斥,特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源
2. 互斥量值只能为0/1,信号量值可以为非负整数。
也就是说,一个互斥量只能用于一个资源的互斥访问,它不能实现多个资源的多线程互斥问题。信号量可以实现多个同类资源的多线程互斥和同步。当信号量为单值信号量是,也可以完成一个资源的互斥访问。
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得到该信号量并接着运行。
在这种情况下,
纠正的方法可以是,
在任务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_***AILABLE表示可用)。
一个优先级,即优先级继承优先级(PIP)。
一个等待mutex的任务列表。
1. 互斥量用于线程的互斥,信号线用于线程的同步。
这是互斥量和信号量的根本区别,也就是互斥和同步之间的区别。
互斥:是指某一资源同时只允许一个访问者对其进行访问,具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序,即访问是无序的。
同步:是指在互斥的基础上(大多数情况),通过其它机制实现访问者对资源的有序访问。在大多数情况下,同步已经实现了互斥,特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源
2. 互斥量值只能为0/1,信号量值可以为非负整数。
也就是说,一个互斥量只能用于一个资源的互斥访问,它不能实现多个资源的多线程互斥问题。信号量可以实现多个同类资源的多线程互斥和同步。当信号量为单值信号量是,也可以完成一个资源的互斥访问。
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_***AILABLE表示可用)。
一个优先级,即优先级继承优先级(PIP)。
一个等待mutex的任务列表。
相关文章推荐
- 轻松理解吞吐量与延迟,信号量与互斥锁
- 轻松理解吞吐量与延迟,信号量与互斥锁
- UCOS2学习笔记:对于信号量,互斥信号量,事件标志组的个人理解
- 对于信号量,互斥信号量,事件标志组的个人理解
- uCos-ii中对于信号量、互斥信号量、事件标志组的理解
- UCOS-II:对于信号量,互斥信号量,事件标志组的个人理解
- 互斥信号量之个人理解---谢谢悦
- 信号量/互斥的理解
- UCOS2:对于信号量,互斥信号量,事件标志组的个人理解
- UCOS-II:对于信号量,互斥信号量,事件标志组的个人理解-转
- UCOS-II:对于信号量,互斥信号量,事件标志组的个人理解
- 信号量/互斥的理解
- 信号量/互斥的理解
- UCOS2:对于信号量,互斥信号量,事件标志组的个人理解
- 对于多线程编程的互斥锁和条件变量以及信号量的理解
- 【Qt开发】QThread中的互斥、读写锁、信号量、条件变量
- Vxworks等实时系统二进制信号量,互斥信号和计数信号量的区别
- linux互斥与同步 之 信号量 读写信号量
- 多线程同步之信号量、互斥量之理解
- 守护进线程,互斥锁,信号量,队列,死锁递归锁等