协作式调度器下实时性能与线程同步问题咨询

1. 是否仍需使用线程同步机制？ #

必须使用。哪怕是协作式调度器，生产者和消费者作为独立线程，只要存在共享数据（比如存储生产数据的缓冲区），就会有数据竞争风险：

• 比如生产者正在写入缓冲区的过程中，消费者可能因为生产者主动让出CPU而被调度执行，此时读取到不完整的数据；
• 或者缓冲区处于“空”状态时消费者尝试读取，“满”状态时生产者尝试写入，导致逻辑错误。
  协作式调度只是线程主动让出CPU，但无法天然保证共享资源的访问顺序，因此必须通过同步机制来约束两个线程的操作时序，避免数据竞争。

2. 替代关中断的低开销高实时性方案 #

针对仅两个线程通信的场景，推荐以下几种更优方案：

双缓冲区（乒乓缓冲区） #

这是一对一生产者消费者场景下的高效方案，完全避免数据竞争，实时性极佳：

• 准备两个独立的缓冲区A和B；
• 生产者固定写入当前激活的缓冲区（比如初始为A），消费者固定读取另一个缓冲区（初始为B）；
• 生产者写完当前缓冲区后，通过一个原子标志位（或在协作式调度下，将标志位更新放在线程主动让出CPU的操作前，确保标志位更新是原子的）切换激活的缓冲区，然后主动让出CPU；
• 消费者读取完当前缓冲区后，同样根据标志位切换读取目标，再让出CPU。
  这种方式下两个线程操作完全独立的内存区域，无需关中断，也不需要复杂的同步原语，开销极低。

二进制信号量（uC/OS-II原生支持） #

利用uC/OS-II提供的二进制信号量实现同步，比关中断的实时性更好：

• 定义两个信号量：sem_empty（标记缓冲区是否可写，初始值为1）和sem_full（标记缓冲区是否可读，初始值为0）；
• 生产者流程：

  OSSemPend(sem_empty, 0, &err); // 获取可写权限
  // 写入数据到缓冲区
  OSSemPost(sem_full); // 标记数据可读
  OSCtxSw(); // 主动让出CPU（协作式调度要求）
  

• 消费者流程：

  OSSemPend(sem_full, 0, &err); // 等待可读取信号
  // 从缓冲区读取数据
  OSSemPost(sem_empty); // 标记缓冲区可写
  OSCtxSw(); // 主动让出CPU
  

信号量的开销远低于关中断，因为它仅针对两个线程的调度，不会屏蔽所有中断，能保证高优先级中断的及时响应，满足实时性要求。

基于协作调度的标志位同步（适合固定周期场景） #

如果生产者和消费者的执行周期固定，且能严格交替执行，可使用简单的共享标志位：

• 定义一个全局标志位buffer_ready，初始为0；
• 生产者写完数据后，将buffer_ready设为1，然后调用OSTimeDly()或OSCtxSw()主动让出CPU；
• 消费者检测到buffer_ready为1时，读取数据，读完后将buffer_ready设为0，再主动让出CPU。
  这种方式几乎没有开销，但依赖严格的调度逻辑，适合对确定性要求极高的简单场景。

内容的提问来源于stack exchange，提问作者kanghao chen