嵌入式C语言：临界区全局变量转栈变量时避免编译器优化

问题背景 #

我正在为软件组件提供RTOS支持，部分场景下需在互斥锁保护的临界区内将全局变量复制到局部变量，再在临界区外的耗时操作中使用该局部副本。但担忧C编译器会优化局部变量赋值，直接使用全局变量，导致消除竞态条件的努力失效。以下是简化的LCD显示示例代码，并提出三个技术疑问：

1. 如何确保局部变量不被编译器优化？
2. 如何确保锁的加解锁与复制操作按预期顺序执行？
3. volatile类型限定符对局部变量是否有帮助？

示例代码 #

uint8_t page_sel = 0;
char lcd_text[PAGE_CNT][ROW_CNT][COLUMN_CNT];

void lcd_print_text(uint8_t page, uint8_t row, const char* text)
{
  lock();
  // 将文本存入代表显示屏内容的全局变量
  copy_text_to_lcd_text(page, row, text);
  unlock();

  // 请求更新显示屏，触发LCD后台任务
  refresh_semaphore_set();
}

void lcd_select_page(uint8_t page)
{
  lock();
  // 存储选中的页码
  page_sel = page;
  unlock();

  // 请求更新显示屏，触发LCD后台任务
  // 页码变化时需更新显示屏
  refresh_semaphore_set();
}

void lcd_task(void)
{
  while(1) {
    // 仅当有修改时更新显示屏
    refresh_semaphore_get();
    refresh();
  }
}

void refresh(void)
{ 
  char page_lcd_text[ROW_CNT][COLUMN_CNT];
  uint8_t page;

  lock();
  // 页码与文本需保持一致，因此需要临界区
  page = page_sel;
  // 创建副本以避免显示更新期间被部分覆盖
  copy_page(page_lcd_text, lcd_text, page);
  // 必须在离开临界区前完成局部副本的创建
  unlock();
  
  // 从文本生成帧缓冲区中的像素数据（耗时操作）
  render_text(page_lcd_text);

  // 生成帧缓冲区中用于显示选中页码的像素数据（耗时操作）
  render_page_num(page);

  // 将像素数据传输到LCD驱动芯片（耗时更长）
  lcd_spi_transfer();
}

问题解答 #

1. 如何确保局部变量不被编译器优化？ #

• 核心依赖RTOS锁函数的内存屏障语义：标准RTOS的lock()/unlock()内部已经包含编译器和硬件层面的内存屏障，会阻止编译器将临界区内的变量复制操作重排到临界区外，也不会用全局变量直接替代局部变量——内存屏障强制编译器认为临界区的内存操作是"不可优化"的。
• 若使用自定义锁（无内置内存屏障），需手动添加编译器屏障：比如GCC用__asm__ __volatile__("" ::: "memory")，MSVC用_ReadWriteBarrier()。该屏障会告知编译器，屏障前后的内存操作不能被重排或省略。

2. 如何确保锁的加解锁与复制操作按预期顺序执行？ #

• 同样依赖锁的内存屏障：lock()隐含获取屏障（acquire barrier），确保临界区内的所有内存操作不会被重排到lock()之前；unlock()隐含释放屏障（release barrier），确保临界区内的所有复制操作完成后才执行unlock()。
• 严格保证lock()与unlock()配对，临界区内仅保留必要的复制操作，避免冗余代码干扰编译器的顺序判断。

3. volatile类型限定符对局部变量是否有帮助？ #

• 几乎没用，甚至可能增加不必要的开销。volatile的作用是告知编译器变量值可能被外部因素（如中断、其他线程）修改，但你的局部变量是在临界区内从全局复制而来，之后仅在当前线程的临界区外使用，外部不会修改它。给局部变量加volatile会强制编译器每次从内存读取该变量，反而降低性能，且无法解决跨临界区的优化问题。
• 补充：若使用标准RTOS锁，共享全局变量也无需加volatile——锁的内存屏障已保证内存可见性和操作顺序；仅在无锁的裸机/原子操作场景下，才需要用volatile防止编译器优化共享变量的读写。

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