#1楼主：浅析μCOS/II v2.85内核OSMutexPend()和OSMutexPost()函数工作原理

文章发表于：2007-09-17 02:35

浅析μCOS/II v2.85内核OSMutexPend()和OSMutexPost()函数工作原理
http://gliethttp.cublog.cn
//优先级翻转问题发生在>=3个进程同时访问一个共享的情况下,
//所以至少有3个进程才有可能发生优先级翻转,即A>B>C时,B才可能将A翻转.
//μCOS/II v2.85内核采用"变相置顶的方式"来解决优先级翻转问题,

//"优先级继承方式"是指一个较高优先级的任务申请某信号量,但此信号量已被一个较低优先级的任务占有,这时,抬升较低优先级任务的优先级到较高优先级任务的优先级,这是一个自动过程.
//"置顶方式"是指一旦有进程访问互斥资源,立即把该进程的优先级提升到置顶值.

//"变相置顶的方式"是指我们根据工程应用任务需要,自己内定一个最高优先级,结合优先级继承方式,根据情况来判断当前task进程优先级是否需要抬升到置顶值.
//这个最高优先级可能不是0,比如可能是5(5空闲,不能用于创建其他任务),原因是0~4,之间的任务不会访问互斥空间,
//仅仅优先级>=6的进程才会访问互斥空间,这时5就是所谓的A,假如优先级为10的进程要访问互斥空间,
//这时因为没有任何进程访问互斥空间,所以10作为pevent->OSEventCnt的低8位值,被保存,之后持有
//互斥空间的操作权利,此时优先级为12的进程也要访问互斥空间,因为12处于C的角色,所以不会发生优先级翻转,
//12将直接被悬停在Mutexevent事件控制矩阵上,之后8打算访问互斥资源空间,
//那么,因为8处于B的角色,这时10需要提升自己到这个所谓的"顶"--优先级5,
//这样,以后所有访问互斥资源的进程都因为优先级小于5而直接悬停在Mutexevent事件控制矩阵上,
//不会出现因为6、7、8悬停在Mutexevent事件控制矩阵上,而此时9因为获得cpu执行权,
//而抢占了10的执行,进而发生优先级翻转现象.[gliethttp]
//但是如果真的0~4中的某个进程不守规矩,贸然访问了共享资源,会发生什么呢,让我们来看看:
//如2要访问资源,那么2一定是直接悬停在事件控制矩阵上,直到已经提升优先级或未提升优先级的占用互斥资源空间
//的进程退出,重新计算悬停在事件控制矩阵上的优先级最高的任务的时候,2将会被加入到就绪控制矩阵中,等待cpu
//调度,进而占用互斥资源,这好像也没有问题,那么继续进行假设,如果4优先级在操作互斥资源,此时2打算操作,
//那么2需要等待,被添加到了mutex事件控制矩阵中,这时就那么巧,3又获得了cpu的使用权,那么优先级4将被3抢占
//所以出现了优先级翻转现象--3把2给翻转了,所以对于优先级高于内定置顶值pip的进程访问互斥资源时,
//并不能受到mutex互斥保护机制的保护,所以对于这些进程,他们可能会发生优先级翻转,也可能不会.
//因此,这使我们更坚定一点,不要存在侥幸心里,踏踏实实的把pip设置成真正的"置顶"值.[gliethttp]
//----------------------------------------------------------------------
//1.OSMutexPend()函数
void OSMutexPend (OS_EVENT *pevent, INT16U timeout, INT8U *perr)
{
    INT8U pip;
    INT8U mprio;
    BOOLEAN rdy;
    OS_TCB *ptcb;
    OS_EVENT *pevent2;
    INT8U y;
    INT8U pend_stat