线程与ISR间的信号量行为及RTOS处理机制咨询

核心结论 #

ISR尝试获取已被占用的信号量时，绝对不会进入阻塞状态——所有RTOS的核心设计都严格禁止ISR阻塞，因为ISR属于中断上下文，必须快速执行完毕返回，否则会导致系统响应异常、甚至死机。

通用处理逻辑 #

当ISR发起信号量获取请求但资源被占用时，RTOS会直接返回"获取失败"的结果，不会让ISR等待。此时开发者需要在ISR中处理这个失败场景：要么放弃当前操作，要么简单记录事件后立即退出，绝不能在这里做循环等待之类的阻塞行为。

FreeRTOS中的具体实现 #

FreeRTOS为ISR上下文提供了专门的信号量API，和任务上下文的API严格区分：

• 任务中使用xSemaphoreTake()（支持阻塞等待）
• ISR中必须使用xSemaphoreTakeFromISR()——这个函数永远不会阻塞，如果信号量不可用，会立即返回pdFALSE，开发者需要根据返回值做后续处理：

  // ISR中的示例代码
  void ExampleISR(void)
  {
      BaseType_t xHigherPriorityTaskWoken = pdFALSE;
      // 非阻塞尝试获取信号量
      if(xSemaphoreTakeFromISR(xSemaphoreHandle, &xHigherPriorityTaskWoken) == pdTRUE)
      {
          // 获取成功，执行临界区操作
          // ...
          // 释放信号量
          xSemaphoreGiveFromISR(xSemaphoreHandle, &xHigherPriorityTaskWoken);
      }
      else
      {
          // 获取失败，直接退出或做简单日志记录
      }
      // 若有高优先级任务被唤醒，请求上下文切换
      portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
  }
  

  注意：FreeRTOS中所有ISR专用的API都带有FromISR后缀，这类接口均不支持阻塞，仅提供非阻塞式的资源尝试。

Linux内核中的处理方式 #

Linux内核中，中断顶半部（严格意义的ISR）同样不能阻塞，处理同步原语时：

• 禁止使用任务态的down()（支持阻塞），必须使用非阻塞版本down_trylock()：

  // 中断上下文示例代码
  irqreturn_t example_isr(int irq, void *dev_id)
  {
      struct semaphore *sem = dev_id;
      // 非阻塞尝试获取信号量
      if(down_trylock(sem) == 0)
      {
          // 获取成功，执行操作
          // ...
          up(sem);
      }
      else
      {
          // 获取失败，直接返回
      }
      return IRQ_HANDLED;
  }
  

  另外，Linux推荐将复杂逻辑放到中断底半部（如tasklet、workqueue）处理，底半部属于进程上下文，可以使用阻塞式同步原语，但这已经不属于严格的ISR范畴。

内容的提问来源于stack exchange，提问作者chaya kumar