ucosIII 共享资源（信号量、互斥信号量）

共享资源：

变量（静态或全局变量）、数据结构体、RAM表格、I/O设备等。OS在使用一些资源时候，例如IO设备打印机，当任务1在使用打印机时候必须保证资源独享，避免其他任务修改打印内容导致出错，因此需要有资源共享机制。

一般推荐使用互斥信号量对共享资源实现保护

独占资源和创建临界区方法表

方法 优点 何时使用 开关中断 能很快地结束访问共享资源，不推荐，会导致中断延迟 访问共享资源时间小于中断关闭时间 锁调度器 不推荐，有悖ucos任务切换 访问共享资源时间大于中断关闭时间，给调度器上锁时间短 信号量 信号量可能会造出优先级反转。然而，信号量方式的执行时间少于互斥信号量 方式 所有的任务可以无限期等待对共享资源的访问 互斥信号量 推荐使用这种方法访问共享资源，有内置的优先级，时间较久 当任务要访问的共享资源有截止时间

只有开关中断才能任务和中断程序共享资源。其它只能用于任务相关的资源共享。

关/开中断

和CPU 相关的操作，其相关代码被放在与CPU相关的文件中（见CPU.H）。uC/OS-III 中与CPU相关的模块叫做uC/CPU。每种架构的CPU 都需要设置相适应的uC/CPU 文件。

API 注释 CPU_SR_ALLOC() 分配存储空间存储当前cpu的中断状态 CPU_CRITICAL_ENTER() 关全局中断 CPU_CRITICAL_EXIT() 开全局中断，恢复局部变量中存储的cpu中断状态

只有这种方法才能任务和中断程序共享资源。只要关中断的时间不比系统本身的关中断时间长，就不会影响到系统的中断延时。

锁调度器

如果任务不需要和ISR 共享资源，就可以通过锁调度器来访问共享资源。
实际上就是禁止任务调度已达到资源的独占

API 注释 OSSchedLock() 锁调度 OSSchedUnlock() 开调度

注意，只有调度器被锁，中断是使能的，如果在处理临界段时中断发生，ISR程序就会被执行。在ISR 的末尾，uC/OS-III会返回原任务（即使ISR中有高优先级任务被就绪）。

支持嵌套250 级。当OSSchedUnlock()与OSSchedLock()被调用的次数相同时调度器才被锁调度器影响了抢占式内核的初衷，内核行为实际与不可剥夺的内核已经是一样的了。

信号量

一种上锁机制，代码需要获取对应的钥匙才能访问共享资源（继续执行），我的理解是实际上只是对访问共享资源区的代码段进行上锁，如果没有获取到钥匙（信号量）则等待无法继续执行，只有别的任务施放了信号量之后才能继续执行下去。

二进制信号量和计数型信号量：

二进制信号量只能取0和1两个值，计数型信号量的信号量值大于1，计数型信号量的范围由OS_SEM_CTR决定，OS_SEM_CTR可以为8位，16位和32位，取值范围分别为：0~255,0~65535和0~4294967295。

二值信号量用于那些一次只能一个任务使用的资源，比如I/O设备，打印机计，数型信号量用于某些资源可以同时被几个任务所使用，比如一个缓存池有10个缓存块，那么同时最多可以支持10个任务来使用内存池。

应用中可以使用任意数量的信号量，但是一般用于IO保护，很多情况下，访问一个简短的共享资源时不推荐使用信号量，请求和释放信号量会消耗CPU时间。

API 注释 OSSemCreate() 创建一个信号量 OSSemDel() 删除一个信号量 OSSemPend() 等待一个信号量 OSSemPendAbort() 取消等待 OSSemPoset() 释放一个信号量 OSSemSet() 强制设置信号量值 OS_SEM 信号量类型

定义一个信号量

OS_SEM XXX 

创建一个信号量

void  OSSemCreate (OS_SEM *p_sem, //信号量结构体，其中OS_SEM_CTR Ctr表示信号量的值                   CPU_CHAR *p_name,//名字                   OS_SEM_CTR cnt,   //信号量初始值                   OS_ERR *p_err)

删除一个信号量

OS_OBJ_QTY  OSSemDel(OS_SEM *p_sem,                     OS_OPT opt,      //1.NO_PEND 仅当没有信号请求的时候才删除     //2.ALWAYS 直接删除，不管有没有信号请求                     OS_ERR *p_err)

请求/等待一个信号量

OS_SEM_CTR  OSSemPend(OS_SEM *p_sem,                       OS_TICK timeout,//等待的时间，如果为0：一直等待下去                      OS_OPT opt,         //1.暂时无效直接挂起 OS_OPT_PEND_BLOCKING         //2.无效直接返回OS_OPT_PEND_NON_BLOCKING                      CPU_TS *p_ts,//时间戳：记录接受信号量的时刻，0或者null则不需要时间戳。                      OS_ERR *p_err)

取消等待

OS_OBJ_QTY  OSSemPendAbort(OS_SEM *p_sem,                           OS_OPT opt,             //1. 仅终止等待该信号量的最高优先级任务             //2. 中止所有的等待该信号量的任务             //3. 禁止任务调度                           OS_ERR *p_err)

释放一个信号量

OS_SEM_CTR OSSemPost(OS_SEM *p_sem,                     OS_OPT opt,              //1. 仅发送给等待该信号量的最高优先级任务              //2. 发送给所有的等待该信号量的任务              //3. 禁止任务调度                     OS_ERR *p_err)

步骤：
先定义OS_SEM
Create创建信号量
OSSemPend等待信号量
OSSemPost释放信号量

互斥信号量

使用信号量访问共享资源会有优先级反转问题：高优先级A任务执行访问共享资源的时候被迫等待低优先级任务D释放信号量，此时会发生任务切换到低优先级。如果此时又有高一级的任务B中断了D的任务，虽然B任务比A任务优先级更低，也会发生任务调度。使得高优先级任务A实际上被拉到占用信号量的低优先级任务D同一优先级别，违背了实时RTOS。

互斥信号量实际解决方法就是，将低优先级任务D的优先级临时提升至任务A同一优先级，等信号量释放后，再将任务D的优先级恢复，这样任务切换只在这两个任务之间执行（如果有比A更高的还是会切换）。

API 注释 OSMutexCreate() 创建一个互斥信号量 OSMutexDel() 删除一个互斥信号量 OSMutexPend() 等待一个互斥信号量 OSMutexPendAbort() 取消等待信号量 OSMutexPost() 释放一个互斥信号量

创建互斥信号量

void  OSMutexCreate(OS_MUTEX  *p_mutex,//指向互斥信号量的控制块                    CPU_CHAR  *p_name, //互斥信号量名字                    OS_ERR    *p_err)//调用此函数后返回的错误码

请求/等待互斥信号量

void  OSMutexPend(OS_MUTEX  *p_mutex, //指向互斥信号量的控制块                  OS_TICK timeout,//指定等待互斥信号量的超时节拍，超时继续执行，0位一直等待                  OS_OPT opt,//是否阻塞             //OS_OPT_PEND_BLOCKING无效挂起             //OS_OPT_PEND_NON_BLOCKING无效直接返回                  CPU_TS *p_ts,//时间戳                  OS_ERR *p_err)//错误码

释放互斥信号量

void  OSMutexPost(OS_MUTEX *p_mutex,//指向互斥信号量                  OS_OPT opt,//指定是否进行任务调度操作    //OS_OPT_POST_NONE不指定特定的选项    //OS_OPT_POST_NO_SCHED 禁止在本函数内执行任务调度                  OS_ERR *p_err)//错误码

步骤：
先定义OS_MUTEX xxxx
Create创建信号量
OSMutexPend等待信号量
OSMutexPost释放信号量

死锁：

任务1需要的资源要等到任务2释放，任务2的资源需要等待任务1释放，造成死锁。
（1）假定任务T1 所等待的事情发生，任务1被执行。
（2）任务T1 申请M1。(mutex 1)
（3）任务T1 访问资源R1。
（4）中断发生，中断中使能了任务T2。由于任务T2 的优先级高于任务T1，CPU 切换到任务T2。
（5）该中断即是任务T2 所等待的事件。
（6）任务T2 申请M2 并占用资源R2。
（7）任务T2 申请M1，但是M1 已被任务T1 占用。任务T2
被挂起。
（8）uC/OS-III 切换到任务T1。
（9）此时任务T1 申请M2，但是M2 已经被任务T2 占用。

此时，两个任务互相等待，这就算死锁。

用以下方式防止死锁：
1）同一个时间不要申请多于一个mutex
2）不要直接地申请mutex（该申请放到器件驱动中和可重入函数中）
3）在处理之前先获得全部所需要的mutex
4）任务间以同样的顺序申请资源

当申请信号量或mutex 时允许设置时间期限，这样能防止死锁，但是同样的死锁可能稍后再次出现。