RISCV单片机wfi休眠与中断竞态问题的解决方案咨询

你的推测方案是可行的，这是解决这类中断竞态问题的标准做法，完全可以实现低功耗休眠且不丢失中断。

为什么之前的尝试存在问题 #

你第二次尝试的代码中，关闭中断检查邮箱为空后，先重新开启中断再执行wfi——这就又引入了新的竞态窗口：从开启中断到执行wfi的间隙，如果主机写入邮箱触发中断，ISR会把消息加入FIFO，但此时wfi已经执行，而新的中断已经处理完毕，没有后续中断触发，处理器会陷入不必要的休眠，导致消息无法及时处理。

正确方案的原理（结合RISC-V中断机制） #

RISC-V的全局中断由mstatus寄存器的MIE（Machine Interrupt Enable）位控制：

• 当MIE为0时，所有全局中断被屏蔽，硬件中断请求会被标记为pending（挂起），但不会触发中断服务程序（ISR）。
• 当MIE重新置1时，挂起的中断会立即触发ISR执行。

正确方案的执行流程完全规避了竞态窗口：

1. 主循环先处理完FIFO中所有消息，直到mail_box_empty()返回真。
2. 关闭全局中断（清除MIE位）：此时ISR不会被触发，邮箱/FIFO的状态不会再被修改。
3. 再次检查邮箱是否为空：
   • 如果为空，执行wfi指令：此时因为中断被屏蔽，即使有新的硬件中断请求，也不会触发ISR，但处理器会进入低功耗休眠；当后续有主机写入邮箱触发硬件中断时，处理器会从wfi唤醒（部分RISC-V实现中，wfi会被任何硬件中断请求唤醒，无论是否允许），接下来开启中断后，挂起的中断会立即触发ISR处理新消息。
   • 如果不为空，说明在第一次检查邮箱和关闭中断之间，已经有中断触发并把消息加入了FIFO，直接跳过休眠步骤。
4. 重新开启全局中断：此时如果有挂起的中断，会立刻进入ISR处理，之后主循环继续处理FIFO中的消息。

更简洁的优化写法 #

你可以把逻辑进一步简化，利用RISC-V wfi的特性——当开启中断且存在挂起的允许中断时，wfi会立即返回，不会进入休眠。结合关中断的原子检查，最终代码可以写成：

while (1)
{
    // 处理所有待处理的邮件
    while (!mail_box_empty())
    {
        process_mail();
    }

    __disable_irq(); // 关闭全局中断（对应RISC-V清mstatus.MIE）
    // 原子性检查：只有邮箱确实为空时才休眠
    if (mail_box_empty())
    {
        __enable_irq(); // 先开中断，再执行wfi，此时若有挂起中断会立即返回
        __asm__ volatile ("wfi");
    }
    else
    {
        __enable_irq(); // 有新消息，直接开中断继续处理
    }
}

注：__disable_irq()和__enable_irq()是编译器内置函数，对应RISC-V的csrci mstatus, 0x8和csrsi mstatus, 0x8指令，不同编译器可能有不同写法，也可以直接用汇编指令实现。

这个优化版本中，开中断后执行wfi，如果此时有挂起的中断，wfi会立刻返回，不会进入休眠，进一步确保不会丢失消息。

内容的提问来源于stack exchange，提问作者Steven Dickinson