韦东山freeRTOS系列教程之【第七章】递归锁实战：解决自我死锁与优先级反转

1. 递归锁：解决自我死锁的利器

第一次在FreeRTOS项目中使用递归锁的场景至今记忆犹新。当时有个任务需要递归调用一个涉及共享资源操作的函数，结果程序直接卡死——这就是典型的自我死锁（Self-Deadlock）。普通互斥量在这种情况下会立即"罢工"，而递归锁却能完美解决这个问题。

递归锁的核心特性是可重入性：持有锁的任务可以多次获取同一个锁而不被阻塞。想象你拿着自家大门钥匙，出门倒垃圾时发现风把门关上了——幸好钥匙还在兜里，这就是递归锁的日常版。在代码层面表现为：

void recursive_function(RecursiveMutex_t *lock, int depth) {
    xSemaphoreTakeRecursive(lock, portMAX_DELAY);  // 第N次获取
    if(depth > 0) {
        recursive_function(lock, depth-1);  // 递归调用
    }
    xSemaphoreGiveRecursive(lock);  // 需要对应释放N次
}

与普通互斥量的关键差异体现在三个方面：

1. 获取计数：内部维护计数器记录获取次数
2. 所有权绑定：严格绑定到首次获取的任务
3. 释放机制：必须由持有者释放相同次数

实测发现，在FreeRTOS v10.4.3中，递归锁的获取耗时比普通互斥量多约15%（在Cortex-M4上约多28个时钟周期），这个开销对于需要递归调用的场景完全可以接受。

2. 自我死锁的典型场景还原

去年调试一个文件系统驱动时遇到过经典案例：任务A获取互斥量后调用库函数，而该库函数内部又尝试获取同一个互斥量。这种"套娃"场景会导致：

1. 使用普通互斥量时：

   • 任务A卡