FreeRTOS篇章之互斥量

最新推荐文章于 2024-03-11 14:32:32 发布
最新推荐文章于 2024-03-11 14:32:32 发布
阅读量3k 收藏 20
点赞数 2
分类专栏： FreeRTOS 文章标签： freertos 信号量 互斥
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_42992084/article/details/104479069
版权

写在前面：
本文章旨在总结备份、方便以后查询，由于是个人总结，如有不对，欢迎指正；另外，内容大部分来自网络、书籍、和各类手册，如若侵权请告知，马上删帖致歉。

 

目录

一、与二值量区别及应用

二、优先级反转

三、优先级继承

四、死锁

五、API函数

六、其他

 

一、与二值量区别及应用

互斥量是一种特殊的二值信号量，用于控制在两个或多个任务间访问共享资源

访问一个被多任务共享，或是被任务与中断共享的资源时，需要采用 “互斥” 技术以保证数据在任何时候都保持一致性。这样做的目的是要确保任务从开始访问资源就具有排它性，直至这个资源又恢复到完整状态

在用于互斥的场合，互斥量从概念上可看作是与共享资源关联的令牌。一个任务想要合法地访问资源，其必须先成功地得到(Take)该资源对应的令牌(成为令牌持有者)。当令牌持有者完成资源使用，其最好马上归还(Give)令牌，因为只有归还了令牌，其它任务才可能成功持有，也才可能安全地访问该共享资源。一个任务除非持有了令牌，否则不允许访问共享资源

它的特性场景：

这种机制纯粹是工作于应用程序作者制定的规则之下。任务不是在任何时候都可以访问资源是不需要理由的，因为这是所有任务达成的一致，除非它们能成为互斥量的持有者

可以对比一下上一篇 FreeRTOS篇章之二值信号量的特性图

虽然互斥量与二值信号量之间具有很多相同的特性，但两者间最大的区别在于信号量在被获得之后所发生的事情：

  • 用于互斥的信号量需要归还。
  • 用于同步的信号量通常是完成同步之后便丢弃，不用归还。

值得注意的是，互斥量不能在中断中使用：

  • 互斥量的优先级继承属性意味着只能在任务间使用
  • 中断在等待一个互斥量保护的资源的时候，不能阻塞

 

二、优先级反转

假设我们创建了两个任务，任务一跟任务二，任务二的优先级高于任务一的优先级，同时还创建了一个互斥量；当运行的时候，任务一获取了这个互斥量（成为令牌持有者），紧接着任务二也需要这个互斥量来共享资源（此时任务一并没有执行完成，释放互斥量），对于正常情况向下，高优先级任务的可以打断低优先任务，但是，由于互斥量的特性（只有归还了令牌，其它任务才可能成功持有，否则不允许访问共享资源，进入阻塞等待令牌归还），高优先级的任务二竟然必须等待低优先级的任务一放弃对互斥量的持有权。因此，高优先级任务被低优先级任务阻塞推迟的行为被称为 “优先级反转”

如果把这种行为再进一步放大，当高优先级任务正等待信号量的时候，一个介于两个任务优先之间的中等优先级任务开始执行 —— 这就会导致一个高优先级任务在等待一个低优先级任务，而低优先级任务却无法执行！

如下图：

 

三、优先级继承

FreeRTOS 中互斥量与二值信号量十分相似 —— 唯一的区别就是互斥量自动提供了一个基本的”优先级继承”机制。

优先级继承是最小化优先级反转负面影响的一种方案 —— 其并不能修正优先级反转带来的问题，仅仅是减小优先级反转的影响。优先级继承使得系统行为的数学分析更为复杂，所以如果可以避免的话，并不建议系统实现对优先级继承有所依赖

优先级继承暂时地将互斥量持有者的优先级提升至所有等待此互斥量的任务所具有的最高优先级；持有互斥量的低优先级任务 “继承” 了等待互斥量的任务的优先级；互斥量持有者在归还互斥量时，优先级会自动设置为其原来的优先级。

优先级继承最小化优先级反转的影响：

 

四、死锁

死锁是利用互斥量提供互斥功能的另一个潜在缺陷。Deadlock 有时候会被更戏剧性地称为 “deadly embrace(抱死)”。

当两个任务都在等待被对方持有的资源时，两个任务都无法再继续执行，这种情况就被称为死锁。考虑如下情形，任务 A与任务 B都需要获得互斥量 X与互斥量 Y以完成各自的工作：

  1. 任务 A执行，并成功获得了互斥量 X。
  2. 任务 A被任务 B抢占。
  3. 任务 B成功获得了互斥量 Y，之后又试图获取互斥量 X —— 但互斥量 X已经被任务 A持有，所以对任务 B无效。任务 B选择进入阻塞态以等待互斥量X 被释放。
  4. 任务 A得以继续执行。其试图获取互斥量 Y ——但互斥量 Y已经被任务 B持有而对任务 A无效。任务 A也选择进入阻塞态以等待互斥量 Y被释放。

这种情形的最终结局是，任务 A在等待一个被任务 B持有的互斥量，而任务 B也在等待一个被任务 A持有的互斥量。死锁于是发生，因为两个任务都不可能再执行下去了。
和优先级反转一样，避免死锁的最好方法就是在设计阶段就考虑到这种潜在风险，这样设计出来的系统就不应该会出现死锁的情况。于实践经验而言，对于一个小型嵌入式系统，死锁并不是一个大问题，因为系统设计者对整个应用程序都非常清楚，所以能
够找出发生死锁的代码区域，并消除死锁问题

 

五、API函数

需要 #include "semphr.h"

功能API 接口实际执行函数其它
互斥量创建（动态）xSemaphoreCreateMutex()xQueueCreateMutex() 
互斥量获取xSemaphoreTake()xQueueGenericReceive() 
互斥量释放xSemaphoreGive()xQueueGenericSend() 
互斥量创建（静态）xSemaphoreCreateMutexStatic()xQueueCreateMutexStatic() 

1、xSemaphoreCreateMutex() API 函数

SemaphoreHandle_t   xSemaphoreCreateMutex( void );

返回参数：

  • NULL：表示互斥量创建失败。原因是内存堆空间不足导致 FreeRTOS 无法为互斥量分配结构数据空间
  • 非 NULL：值表示互斥量创建成功。返回值应当保存起来作为该互斥量的句柄

2、xSemaphoreTake() API 函数

BaseType_t   xSemaphoreTake( SemaphoreHandle_t    xSemaphore,
                                                    TickType_t                    xBlockTime );

传入参数：

  • xSemaphore：获取得到的信号量。信号量由定义为 xSemaphoreHandle类型的变量引用；信号量在使用前必须先创建
  • xTicksToWait：阻塞超时时间。任务进入阻塞态以等待信号量有效的最长时间。如果 xTicksToWait 为0，则 xSemaphoreTake()在信号量无效时会立即返回；如果把 xTicksToWait 设置为 portMAX_DELAY，那么阻塞等待将没有超时限制

返回参数（有两个可能的返回值）：

  • pdTRUE：成功获得信号量
  • pdFALSE：未能获得信号量

3、xSemaphoreGive() API 函数

BaseType_t   xSemaphoreGive( SemaphoreHandle_t    xSemaphore );

传入参数：

  • xSemaphore：给出的信号量。信号量由定义为 xSemaphoreHandle类型的变量引用；信号量在使用前必须先创建

返回参数（有两个可能的返回值）：

  • pdTRUE：信号量被释放
  • pdFALSE：信号量已经有效，无法给出

4、xSemaphoreCreateMutexStatic() API函数

SemaphoreHandle_t   xSemaphoreCreateMutexStatic( StaticSemaphore_t *pxMutexBuffer );

该函数是用于在静态的时候，利用该函数创建一个互斥量的，具体可以去看他的注释，这里就不说了

值得注意的是：当用 xSemaphoreCreateMutexStatic创建一个静态互斥量后，该互斥量量是默认 “Give” 给出去了的，所以在 xSemaphoreCreateMutexStatic创建后没有立即调用 xSemaphoreTake，那么，它将通过你的第一次阻塞处理

 

六、其他

这里就不放整个例程了，跟 FreeRTOS篇章之队列管理中差不多，只不过用互斥量来处理；像我们常用的多线程 printf输出会出现乱码现象，可以如以下处理：

extern SemaphoreHandle_t MuxSem_UartPrintf;
#define USER_DEBUG				1
#define DEBUG_PRINTF(fmt,arg...)			do{\
											if(USER_DEBUG)\
												xSemaphoreTake(MuxSem_UartPrintf, portMAX_DELAY);\
												printf("<<-DEBUG INFO->> %s > "fmt"",__FUNCTION__, ##arg);\
												xSemaphoreGive(MuxSem_UartPrintf);\
											}while(0)

然后，我们只需要在硬件初始化化的创建好互斥量，后面就可以用 DEBUG_PRINTF宏来打印无乱码现象的数据输出了，而且还可以通过 USER_DEBUG宏来选择时候显示调试信息

前面也都说了，为了避免在 RTOS中多个任务同时访问公用数据共享资源（或者同一硬件），因此，当有一个任务在访问处理共享资源时，其他的任务要停止对共享资源的访问，以避免出现数据访问（或处理）出错，所以可以用互斥量来处理这些问题；当然在使用互斥量的时候要注意上面所说的那一些缺陷

 

最后，说一下递归互斥量：

递归互斥量(Recursive Mutexes)是互斥量的一个特例，与互斥量基本相同；除了：递归互斥量可以由拥有者多次获取，但是也要求拥有者释放相同次数。比如，一个递归互斥量被获取了 5次，那么同样需要释放 5次

夏沫の浅雨
关注
  • 2
    点赞
  • 踩
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
NXP i.MX RT1052 FreeRTOS实战：互斥量
12-01
NXP i.MX RT1052 FreeRTOS实战。 NXP i.MX RT1052驱动程序。 资源代码可直接编译、运行。
FreeRTOS递归互斥信号量（含IAR和MDK）.rar
05-16
任务 Task1 运行的过程需要调用函数 printf，发现任务 Task3 正在调用，任务 Task1 会被挂起，等待 Task3 释放函数 printf。 在调度器的作用下，任务 Task3 得到运行，Task3 运行的过程中，由于任务 Task2 就绪，抢占了 Task3的运行。 优先级翻转问题 就出在这里了，从任务执行的现象上看，任务 Task1 需要等待 Task2 执行完毕才有机会得到执行，这个与抢占式调度正好反了，正常情 况下应该是高优先级任务抢占低优先级任务的执行，这里成了高优先级任务 Task1 等待低优先级任务 Task2 完成。 所以这种情况被称之为 优先级翻转问题。 任务 Task2 执行完毕后，任务 Task3 恢复执行，Task3 释放互斥资源后，任务 Task1 得到互斥资源，从而可以继续执行。上面就是一 个产生优先级翻转问题的现象。
FreeRTOS操作系统学习——互斥量
最新发布
纵行山河万里~
03-11 931
互斥量又称互斥信号量（本质是信号量），是一种特殊的二值信号量，它和信号量不同的是，它支持互斥量所有权、递归访问以及防止优先级翻转的特性，用于实现对临界资 源的独占式处理。任意时刻互斥量的状态只有两种，开锁或闭锁。当互斥量被任务持有时， 该互斥量处于闭锁状态，这个任务获得互斥量的所有权。当该任务释放这个互斥量时，该 互斥量处于开锁状态，任务失去该互斥量的所有权。当一个任务持有互斥量时，其他任务 将不能再对该互斥量进行开锁或持有。持有该互斥量的任务也能够再次获得这个锁而不被。
STM32H743 FreeRTOS实现互斥信号量操作【支持STM32H7系列单片机_FreeRTOS操作系统】.zip
01-30
STM32H743 FreeRTOS实战。 项目支持STM32H7系列单片机调测和移植。 项目代码可直接编译、运行。
Free RTOS脑图文件之信号量（包括互斥量、递归互斥量）
05-02
自己总结的Free RTOS脑图文件，方便查询记忆。
FreeRTOS_信号量之互斥信号量
light_2025的博客
11-01 414
意思就是说：低优先级的任务获得互斥信号量，此时高优先级的任务无法访问获得互斥信号量，其他中等优先级的任务也无法获得互斥信号量，这样一来，低优先级任务就不能被中等优先级任务所打断，高优先级任务只需要等待低优先级任务释放互斥信号量即可，不用担心被其他的中等任务所打断；：低优先级任务正在使用互斥信号量，而高优先级任务请求使用互斥信号量，此时会临时的将低优先级任务的优先级提高到和高优先级任务一个层次，这时被提升上来的任务就不会被其他优先级任务所打断，最大程度保证高优先级任务尽快获得互斥信号量，提高系统的响应性能。
FreeRTOS信号量详解第四讲（全网最全）——互斥信号量
留小乙的博客
10-26 6685
一、互斥信号量简介 互斥信号量其实就是一个拥有优先级继承的二值信号量，在同步的应用中（任务与任务或中断与任务之间的同步）二值信号量最适合。互斥信号量适合用于那些需要互斥访问的应用中。在互斥访问中互斥信号量相当于一个钥匙，当任务想要使用资源的时候就必须先获得这个钥匙，当使用完资源以后就必须归还这个钥匙，这样其他的任务就可以拿着这个钥匙去使用资源。互斥信号量使用和二值信号量相同的API操作函数，所以互斥信号量也可以设置阻塞时间，不同于二值信号量的是互斥信号量具有优先级继承的特性。当一个互斥信号量正在被一个低优先
FreeRTOS（5）----互斥量
weixin_63032791的博客
05-20 1603
优先级继承算法指的是暂时提高某个占用某种资源的低优先级的任务，使得在等待该资源的任务中优先级最高的任务优先级相等，当原本占有资源的任务释放了资源后，优先级恢复为原来的设定值。在系统中，一般高优先级的任务就代表了这个任务越重要，越要优先执行，但在互斥访问中，高优先级任务访问的资源被上锁，导致变为挂起态，在freertos中，紧急的任务无法得到快速处理，则会对系统产生很大的危害。】，此时优先级的继承机制就要发挥作用了，把当前占用资源的低优先级的任务提升到和高优先级任务一样的优先级。·任务L正常运行，占用资源。
FreeRTOS个人笔记-互斥量
weixin_47077788的博客
07-25 1438
根据个人的学习方向，学习FreeRTOS。由于野火小哥把FreeRTOS讲得比较含蓄，打算在本专栏尽量细化一点。作为个人笔记，仅供参考或查阅。配套资料FreeRTOS内核实现与应用开发实战指南、野火FreeRTOS配套视频源码、b站野火FreeRTOS视频。搭配来看更佳哟！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
FreeRTOS学习篇六：互斥量
weixin_45647341的博客
09-11 369
FreeRTOS互斥量的基本概念与特性介绍，以及常用的互斥量操作函数的使用介绍。
FreeRTOS的互斥量
嵌入式之斋
04-03 315
例如，创建一个互斥量可以使用函数xSemaphoreCreateMutex()，获取互斥量可以使用函数xSemaphoreTake()，释放互斥量可以使用函数xSemaphoreGive()。由于互斥量的特性，同一时刻只有一个任务能够获得该互斥量，从而保证了对临界资源的独占式访问。支持防止优先级翻转：当一个低优先级任务持有互斥量时，高优先级任务不能获取该互斥量，从而避免了优先级翻转的问题。支持互斥量所有权：一个任务可以持有一个互斥量并防止其他任务获取它，只有持有互斥量的任务才能访问临界资源。
stm32f103 FreeRTOS互斥信号量操作实验.zip
03-07
此程序为STM32F103 移植FreeRTOS系统工程源码，有需要可以学习参考，特别适合刚入门， 或者还没有入门的单片机开发者，可以提高代码开发周期，提升编程水平
FreeRTOS系列|互斥信号量
kunkliu的博客
05-25 1406
互斥信号量 1. 优先级翻转 优先级翻转是使用二值信号量时常遇见的问题，在可剥夺内核中非常常见，但是在实时系统中不允许出现这种现象，因为会破坏任务的预期顺序，可能会导致严重后果。 如下图所示的优先级翻转的例子： 低优先级任务L要访问共享资源，在获取到信号量使用CPU的过程中，如果此时高优先级任务H到达，会剥夺L的CPU使用权从而运行任务H当H想要访问共享资源时，由于此时该资源的信号量仍被L占用着，H只能挂起等待L释放该信号量L继续运行，此时中优先级任务M到达，再次剥夺L的CPU使用权从而运行任务
FreeRTOS 信号量(四) ------ 互斥信号量
Bit_Dong的博客
04-28 1460
互斥信号量其实就是一个拥有优先级继承的二值信号量，在同步的应用中(任务与任务或中断与任务之间的同步)二值信号量最适合。互斥信号量适合用于那些需要互斥访问的应用中。在互斥访问中互斥信号量相当于一个钥匙，当任务想要使用资源的时候就必须先获得这个钥匙，当使用完资源以后就必须归还这个钥匙，这样其他的任务就可以拿着这个钥匙去使用资源。互斥信号量使用和二值信号量相同的 API 操作函数，所以互斥信号量也可以设置阻塞时间，不同于二值信号量的是互斥信号量具有优先级继承的特性。
FreeRTOS——互斥量
weixin_44567318的博客
07-21 1748
FreeRTOS——互斥量互斥量 互斥量 互斥量是包含优先级继承机制的二进制信号量。二进制信号量是实现同步（任务之间或任务与中断之间）的更好选择，而互斥量是实现简单互斥的更好选择。 当用于互斥时，互斥量就像一个用于保护资源的令牌。当任务希望访问资源时，它必须首先获得（“获取”）令牌。当它完成资源的使用后，它必须“释放”令牌——允许其他任务有机会访问相同的资源。 互斥量与信号量使用相同的访问 API 函数，因此也允许指定阻塞时间。阻塞时间表示如果互斥量不是立即可用的，则在尝试“获取”互斥量时，任务应进入阻塞状
【Freertos基础入门】深入浅出freertos互斥量
m0_62599305的博客
08-20 614
FreeRTOS是一款开源的实时操作系统，提供了许多基本的内核对象，其中包括互斥锁（Mutex）。互斥锁是一种常用的同步机制，用于确保在同一时间内只有一个任务可以访问共享资源，防止竞态条件等并发问题。本文将介绍FreeRTOS中的互斥锁的使用方法和注意事项。互斥锁是FreeRTOS提供的一个重要的同步机制，用于控制对共享资源的访问。通过仔细使用互斥锁，可以防止并发问题如竞态条件、死锁等的发生。本文简要介绍了在FreeRTOS中使用互斥锁的基本方法，包括创建、获取、释放和处理错误。
FreeRTOS笔记（六）互斥量mutex
m0_58575472的博客
03-14 1364
在上图中，有个低优先级的任务（LP）和高优先级的任务（HP），两个任务都可以对一个资源进行操作。如果一个保存数据的全局变量在被一个任务操作的过程中，又被多个更高优先级的任务抢占并处理，那么最后这个支离破碎的数据将会毫无意义，破坏了数据的独立完整性；从外部的视角看，此时中等优先级的任务MD相当于抢占了高优先级的任务HP，而高优先级的任务HP表现起来却又像是有最低的优先级。优先级继承会暂时提高获得互斥量的任务的优先级，使得含有互斥量的任务的优先级和想要获取互斥量的任务中的最高优先级一样。宏定义会再次打开中断。
FreeRTOS学习笔记4
qq_50299271的博客
09-28 479
FreeRTOS 互斥量的使用
FreeRTOS互斥量 基于STM32
热门推荐
qq_61672347的博客
07-04 1万+
FreeRTOS基于STM32的互斥量创建，删除，获取，释放等操作
利用stm32的freertos操作系统互斥量
06-03
在使用STM32的FreeRTOS操作系统时，互斥量可以用于保护共享资源，以确保在一定时间内只有一个任务可以访问该资源。 下面是在STM32上使用FreeRTOS操作系统中互斥量的基本步骤： 1. 首先需要在FreeRTOS中创建互斥量。 ```c SemaphoreHandle_t xMutex = xSemaphoreCreateMutex(); ``` 2. 在需要保护共享资源的任务中获取互斥量。 ```c xSemaphoreTake(xMutex, portMAX_DELAY); ``` 如果互斥量不可用，任务会一直等待，直到互斥量可用。 3. 在完成对共享资源的访问后，释放互斥量。 ```c xSemaphoreGive(xMutex); ``` 这样可以使其他任务可以访问该共享资源，并保护共享资源不被多个任务同时访问。 需要注意的是，在获取互斥量后，必须在适当的时候释放互斥量，否则可能会导致其他任务无法访问该共享资源。同时，还需要注意避免死锁的情况发生，即多个任务都互相等待对方释放互斥量，导致任务无法继续执行。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值