信号量核心API实战：创建/删除/获取/释放信号量

各位同学，今天我们来啃一块硬骨头——信号量的核心API。说实话，我刚入行那会儿，觉得信号量就是个计数器，没什么了不起。直到我在一个电机控制项目里，因为信号量释放顺序搞反了，电机直接飞车……嗯，从那以后，我再也不敢小看这几个API了。

信号量是什么？先别急着背定义

你想想看，在实时系统里，多个任务同时跑，就像厨房里好几个厨师同时做菜。有人要拿盐，有人要拿糖，还有人要拿锅铲。如果没人管，肯定乱套。信号量就是那个「资源管理员」。

说白了，信号量就是一个整数，加上两个操作：获取（take）和释放（give）。获取时减1，释放时加1。当信号量值为0时，获取操作会让任务阻塞等待。

创建信号量：从无到有

以FreeRTOS为例，创建信号量有两种方式：

// 方式一：创建二进制信号量（用于同步）
SemaphoreHandle_t xSemaphore = xSemaphoreCreateBinary();

// 方式二：创建计数型信号量（用于资源管理）
SemaphoreHandle_t xSemaphore = xSemaphoreCreateCounting(5, 5);
// 参数1：最大计数值  参数2：初始计数值

我个人习惯用计数型信号量管理资源池。比如一个串口DMA缓冲区有5个槽位，初始值就设5。每个槽位被占用时获取一次，释放时归还一次。

获取信号量：等还是不等？

获取信号量时，你可以选择「死等」还是「超时返回」。这取决于你的应用场景。

// 方式一：无限等待（阻塞直到获取成功）
if (xSemaphoreTake(xSemaphore, portMAX_DELAY) == pdTRUE) {
    // 成功获取，开始使用资源
}

// 方式二：超时等待（等100ms，拿不到就返回）
if (xSemaphoreTake(xSemaphore, pdMS_TO_TICKS(100)) == pdTRUE) {
    // 拿到了
} else {
    // 超时了，做其他处理
}

我曾经在一个数据采集项目里，用无限等待获取信号量。结果某个传感器偶尔卡死，导致整个采集任务永远阻塞。后来改成超时等待+重试机制，问题就解决了。

释放信号量：别忘了还回去

释放操作看起来简单，但坑不少：

// 任务中释放
xSemaphoreGive(xSemaphore);

// ISR中释放（必须用这个版本）
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

注意那个 xHigherPriorityTaskWoken 参数。如果释放信号量后，有更高优先级的任务被唤醒，这个变量会被设为pdTRUE。这时候你需要手动触发一次上下文切换。

我记得有个同事，在ISR里释放信号量后忘了检查这个标志，结果高优先级任务一直得不到执行，系统响应延迟了200多微秒。在高速控制系统中，这足以让PID调节失效。

删除信号量：善始善终

vSemaphoreDelete(xSemaphore);
xSemaphore = NULL;  // 记得置空，防止野指针

删除信号量时，如果有任务正在等待这个信号量，这些任务会全部解锁并返回错误。所以删除前最好确保没有任务在等待。

实战场景：任务间同步

来看一个典型的生产者-消费者模型：

// 生产者任务
void vProducerTask(void *pvParameters) {
    while(1) {
        // 采集数据
        uint32_t data = readSensor();
        // 写入缓冲区
        writeToBuffer(data);
        // 通知消费者
        xSemaphoreGive(xDataReadySem);
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

// 消费者任务
void vConsumerTask(void *pvParameters) {
    while(1) {
        // 等待数据就绪
        if (xSemaphoreTake(xDataReadySem, pdMS_TO_TICKS(100)) == pdTRUE) {
            uint32_t data = readFromBuffer();
            processData(data);
        } else {
            // 超时处理：可能传感器故障
            handleTimeout();
        }
    }
}

这个模式我在很多项目里用过。比如一个温控系统，传感器采集任务每50ms产生一次数据，控制任务等待信号量后处理。这样两个任务完全解耦，互不干扰。

实战场景：资源管理

假设你有3个相同的硬件定时器，多个任务需要申请使用：

// 初始化：创建计数信号量，初始值3
SemaphoreHandle_t xTimerSem = xSemaphoreCreateCounting(3, 3);

// 申请定时器
int requestTimer() {
    if (xSemaphoreTake(xTimerSem, pdMS_TO_TICKS(500)) == pdTRUE) {
        // 分配一个空闲定时器
        int timerId = allocateTimer();
        return timerId;
    }
    return -1;  // 申请失败
}

// 释放定时器
void releaseTimer(int timerId) {
    freeTimer(timerId);
    xSemaphoreGive(xTimerSem);
}

这样做的好处是：任务不用关心具体哪个定时器空闲，信号量自动帮你做计数管理。我曾经用这个方式管理4个DMA通道，代码简洁多了。

避坑指南：我踩过的雷

• 优先级反转：低优先级任务持有信号量，高优先级任务等待，中优先级任务抢占了CPU。结果高优先级任务被中优先级任务间接阻塞。解决方案是使用互斥量（带优先级继承），而不是二进制信号量。
• 死锁：任务A持有信号量1，等待信号量2；任务B持有信号量2，等待信号量1。两个任务互相等待，永远解不开。我建议：所有任务按相同顺序获取信号量，或者使用超时获取。
• 信号量泄漏：获取了信号量但忘记释放。特别是在错误处理路径上，很容易漏掉释放操作。我习惯用goto语句统一做清理，或者用RAII思想封装。

知识体系总览

下面这张图总结了信号量API的核心逻辑：

总结一下

信号量API其实就四个动作：创建、获取、释放、删除。但每个动作背后都有讲究。创建时选对类型，获取时想好超时策略，释放时别忘了ISR的特殊处理，删除前确认没有任务在等待。

我个人觉得，信号量用得好不好，不在于你背了多少API参数，而在于你能否在复杂的任务交互中，保持资源管理的清晰和稳定。多想想「谁在等？谁在用？谁在释放？」这三个问题，大部分问题都能避免。

---