1. 优先级反转：一个必须直面的实时性陷阱
在嵌入式实时系统中，“实时”二字并非指“快”，而是指“确定性”——任务必须在严格限定的时间窗口内完成。FreeRTOS作为轻量级实时操作系统，其调度器基于优先级抢占机制：高优先级任务就绪时，立即剥夺低优先级任务的CPU使用权。这一机制简洁高效，却在共享资源场景下埋下了一个隐蔽而危险的雷：优先级反转（Priority Inversion）。
优先级反转不是理论缺陷，而是真实世界中反复出现的工程故障。它的典型表现极具迷惑性：最高优先级任务（Task_High）因等待某个临界资源而阻塞，但该资源却被一个低优先级任务（Task_Low）持有；此时，一个中等优先级任务（Task_Mid）恰好就绪并开始运行，它既不与Task_High竞争资源，也不受Task_Low影响，于是持续占用CPU。结果就是：Task_High被Task_Mid“卡住”，其响应时间远超预期，实时性保障彻底失效。
这种现象违背了开发者对优先级调度的直觉认知。你精心设计的高优先级任务，本应第一时间响应关键事件（如紧急中断处理、高速数据采集），却可能因一个后台低优先级任务（如日志写入、状态轮询）而被“降级”为最低响应等级。在工业控制、医疗设备或汽车电子中，这种延迟足以导致系统失控。因此，理解其成因并掌握其解决方案，是嵌入式工程师构建可靠实时系统的必修课。
2. 互斥量（Mutex）：专为解决优先级反转而生
FreeRTOS提供了两种核心同步原语：二值信号量（Binary Semaphore）和互斥量（Mutex）。二者在API层面高度相似，均用于任务间同步与资源访问控制，但其底层实现与设计哲学存在本质差异。
