pthread_getschedparam 获取线程调度策略和优先级失败的常见原因
调用 pthread_getschedparam 返回非零值（比如 EINVAL 或 ESRCH），大概率不是函数写错了，而是传入了非法线程 ID 或未初始化的 struct sched_param*。注意：该函数不接受 0 或主线程的“伪 ID”以外的任意整数——必须是真实、存活且可访问的 pthread_t 值；同时 sched_param 结构体哪怕只读优先级，也得先清零（memset(¶m, 0, sizeof(param))），否则部分系统（如某些 glibc 版本）会因未识别字段拒绝调用。
- 确保线程仍在运行（已
join或detach后的pthread_t不再有效） - 检查
policy指针和param指针是否非空，且param至少有sizeof(sched_param)字节可写 - 在容器中保存
pthread_t时，避免仅靠局部变量生命周期管理——线程可能早于变量销毁就结束了
设置实时优先级（SCHED_FIFO/SCHED_RR）需要 root 权限或 cap_sys_nice
即使代码里调用 pthread_setschedparam 成功返回 0，也不代表优先级真生效了。Linux 默认禁止普通用户提升调度策略到实时类（SCHED_FIFO、SCHED_RR），此时 errno 可能是 EPERM，但有些旧版 glibc 会静默降级为 SCHED_OTHER 而不报错。验证是否真正生效，不能只看返回值，得紧接着调用 pthread_getschedparam 对比回读的 policy 和 param.sched_priority。
- 普通用户可设的
SCHED_OTHER优先级范围固定为 0，所谓“调整”只是影响 CFS 的vruntime权重（通过nice()），和pthread_setschedparam无关 - 若需免 root 使用实时策略，启动前用
sudo setcap cap_sys_nice+ep ./your_program授权，而非直接加 sudo -
SCHED_RR时间片由内核决定（通常几 ms），无法通过 API 设置；改时间片需改内核参数（/proc/sys/kernel/sched_rr_timeslice_ms），且影响全局
pthread_setschedparam 修改后不立即抢占？要看当前线程状态
成功设置更高优先级后线程没立刻被调度，往往是因为它正阻塞在某个系统调用（如 read()、sem_wait()）或处于 sleeping 状态。POSIX 并不要求内核在参数变更瞬间中断当前执行流——只有当线程下一次变为可运行态（例如 IO 完成、锁释放、定时器到期），调度器才会按新策略和优先级重新评估其运行资格。
- 若线程在自旋等待（busy-wait），它一直占用 CPU，新优先级要等下次被抢占（如时间片用完）才起作用
- 对正在执行的线程调用
pthread_setschedparam，不会触发立即重调度；可用sched_yield()主动让出 CPU，促使调度器重新选择 - 多核下，高优先级线程可能被绑定在某个 CPU 上（
pthread_setaffinity_np），而目标 CPU 正忙，也会延迟响应
跨平台兼容性：macOS 和 Windows 不支持 pthread_set/getschedparam
这两个函数是 POSIX.1b 实时扩展的一部分，在 macOS 上完全不可用（链接时报 undefined symbol），Windows 的 pthread 实现（如 pthreads-win32）也多数只 stub 了返回 ENOSYS。如果代码需要兼顾，别硬写条件编译包裹，更稳妥的做法是：检测运行时环境，对非 Linux 系统降级使用 setpriority(PRIO_PROCESS, 0, nice_value)（仅影响 SCHED_OTHER 相对权重），或直接记录警告并跳过调度策略操作。
立即学习“C++免费学习笔记（深入）”；
- 编译期判断不可靠：
#ifdef __linux__会误伤 Android（虽是 Linux 内核但 Bionic libc 不完全兼容） - 运行时检查可用性：尝试调用
pthread_getschedparam(pthread_self(), &pol, ¶m)并捕获返回值，比宏更准 - 别把
pthread_setschedparam当作性能优化银弹——在非实时场景下，过度依赖它反而增加调度抖动
真正难的不是调用那两行函数，而是搞清你的线程此刻在内核眼里是什么状态、受哪些资源限制、以及调度策略变更后内核到底怎么决策。很多问题到最后，都卡在“以为设了，其实没生效”或者“生效了，但没按预期表现”。
