多线程餐厅模拟C程序调试求助：__pthread_tpp_change_priority断言失败

• 检查线程优先级设置代码
  这个断言触发的核心原因是设置的线程优先级超出了FIFO调度策略的合法范围。排查代码中所有调用pthread_setschedparam()、pthread_attr_setschedparam()或直接修改线程优先级的地方，确认传入的new_prio值是否满足：要么是-1（不修改优先级），要么在系统定义的fifo_min_prio到fifo_max_prio区间内。可以用sched_get_priority_min(SCHED_FIFO)和sched_get_priority_max(SCHED_FIFO)获取合法范围，对比你设置的数值。

• 排查Valgrind环境下的特殊行为
  Valgrind对线程调度的模拟和原生环境有差异，正常运行时没暴露的优先级问题可能被触发。先尝试不使用Valgrind运行程序，看是否出现相同或其他错误，缩小问题范围。如果仅在Valgrind下触发，注意是否是Valgrind对线程属性的限制导致，比如它可能不支持某些优先级设置。

• 检查线程属性初始化与销毁
  确认所有pthread_attr_t对象都正确调用pthread_attr_init()初始化、pthread_attr_destroy()销毁。如果属性对象未初始化就用来设置优先级，可能出现非法随机值，触发断言。

• 排查多线程同步代码的副作用
  断言虽和优先级相关，但可能是同步逻辑（锁、信号量）的错误间接导致线程优先级被意外修改。比如持有锁时调用了修改线程属性的函数，或信号量等待/唤醒过程中触发系统对线程优先级的调整。检查所有同步操作前后的线程状态相关代码。

• 对比不同编译器的报错信息
  整理不同编译器下的报错内容，它们可能指向同一问题的不同表现形式。比如GCC报优先级非法，Clang报线程属性错误，结合这些信息能更快定位问题点。

• 逐步简化代码定位问题
  剥离餐厅模拟的复杂逻辑，先写最小复现案例：创建几个线程，设置相同的优先级和调度策略，看是否触发断言。如果最小案例正常，再逐步添加同步逻辑、餐厅业务代码，每添加一部分就测试，直到触发错误，精准定位问题代码段。

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