Linux下须用sched_getaffinity将亲和性写入cpu_set_t结构体，返回值仅为调用结果；Windows用GetProcessAffinityMask获取整数掩码，注意位图含义与超线程影响；跨平台应封装为CPU索引集合而非统一整数掩码。
Linux下用 sched_getaffinity 读取当前线程的CPU亲和性掩码
Linux不直接暴露“亲和性屏蔽位”为一个整数，而是通过 cpu_set_t 结构体传递。调用 sched_getaffinity 是唯一标准方式，它把当前线程（或指定PID）实际生效的CPU集合写入该结构体。
常见错误是误以为返回值就是掩码整数——其实返回值是系统调用结果（0成功，-1失败），真正数据在传入的 cpu_set_t* 缓冲区里：
#include <sched.h>
#include <stdio.h>
#include <unistd.h>
cpu_set_t mask;
CPU_ZERO(&mask);
if (sched_getaffinity(0, sizeof(mask), &mask) == 0) {
for (int i = 0; i < CPU_SETSIZE; i++) {
if (CPU_ISSET(i, &mask)) {
printf("CPU %d is allowed\n", i);
}
}
}
-
CPU_SETSIZE通常为1024，但实际可用CPU数可能更小，建议配合sysconf(_SC_NPROCESSORS_ONLN)校验 - 若程序未显式设置过亲和性，返回的是继承自父进程（通常是全核）的掩码，不是“系统默认”硬编码值
- 注意
sizeof(mask)必须准确；用错大小会导致读越界或截断，sched_getaffinity可能静默失败
Windows下用 GetProcessAffinityMask 获取进程级掩码
Windows区分进程级和线程级亲和性，但大多数场景下关心的是进程掩码，对应API是 GetProcessAffinityMask。它返回两个 DWORD_PTR：第一个是进程允许运行的CPU掩码，第二个是系统可用CPU掩码（即“硬上限”）。
关键点在于：返回的掩码是低位有效、按物理CPU编号排列的位图，但Windows可能启用逻辑处理器超线程，此时第0位未必对应物理核心0：
立即学习“C++免费学习笔记（深入）”；
#include <windows.h>
#include <iostream>
DWORD_PTR proc_mask, sys_mask;
if (GetProcessAffinityMask(GetCurrentProcess(), &proc_mask, &sys_mask)) {
std::cout << "Process affinity mask: 0x" << std::hex << proc_mask << "\n";
}
- 若返回
false，需用GetLastError()判断原因，常见是权限不足（如被调试器或组策略限制） - 64位程序中
DWORD_PTR是64位，但旧版Windows可能只支持低32位；检查sys_mask才知真实CPU数量上限 - 该API不反映线程单独调用
SetThreadAffinityMask的效果——线程级设置优先于进程级，但GetProcessAffinityMask读不到线程级覆盖
跨平台封装时别直接拼整数掩码
不同系统对“掩码”的定义不一致：Linux的 cpu_set_t 是位数组结构体，Windows返回原生整数，而macOS压根不提供等价接口（仅支持 thread_policy_set 设置，不可读）。强行统一成一个 uint64_t 掩码会掩盖关键差异。
更稳妥的做法是封装为可枚举的CPU索引集合：
// 伪代码示意
std::vector<int> get_allowed_cpus() {
#ifdef _WIN32
DWORD_PTR m; GetProcessAffinityMask(..., &m, ...);
std::vector<int> res;
for (int i = 0; i < 64 && m; i++, m >>= 1) {
if (m & 1) res.push_back(i);
}
return res;
#else
cpu_set_t set; sched_getaffinity(..., &set);
std::vector<int> res;
for (int i = 0; i < CPU_SETSIZE; i++) {
if (CPU_ISSET(i, &set)) res.push_back(i);
}
return res;
#endif
}
- 不要假设最多64核——Linux
CPU_SETSIZE可能更大，Windows在某些服务器版本支持 >64 逻辑处理器，需动态探测 - macOS无标准读取接口，
host_processor_info只能查在线状态，无法得知调度限制，此时应明确报错或降级为“全部可用” - 多线程环境下，获取结果仅代表调用时刻的快照；若其他线程正在调用
sched_setaffinity或SetThreadAffinityMask，结果可能立即过期
为什么 pthread_getaffinity_np 不推荐直接用
glibc提供了 pthread_getaffinity_np，但它属于GNU扩展（_np = non-portable），且行为与 sched_getaffinity 不完全一致：它操作的是线程对象本身，而 sched_getaffinity 操作的是内核调度实体（task_struct）。在使用线程池或协程库（如libco、Boost.Fiber）时，前者可能返回错误的掩码。
- POSIX标准不保证线程级亲和性API的存在，依赖
_np函数会让代码失去可移植性 - 即使在同一Linux发行版上，musl libc 完全不提供
pthread_getaffinity_np，编译直接失败 - 真正需要线程粒度控制时，应优先用
sched_getaffinity配合pthread_getattr_np获取线程ID再传入，而非依赖pthread专属接口
