支持超过64个处理器的C++ DLL：修改要求与每处理器数据结构咨询

来自微软官方处理器组文档的核心约束：如果应用程序使用带有每处理器数据结构的DLL，且该DLL未经过修改以支持超过64个逻辑处理器，那么该应用中所有调用此DLL导出函数的线程必须被分配到同一处理器组。

问题1：“DLL经过修改以支持超过64个逻辑处理器”的具体含义 #

Windows在逻辑处理器总数超过64时，会将所有逻辑处理器划分为多个独立的处理器组，每组最多包含64个逻辑处理器，早期API默认仅能操作当前线程所在组内的处理器。
所谓“经过修改支持超64逻辑处理器”，本质是DLL不再默认假设系统仅存在单一处理器组、所有调用导出函数的线程处于同一个亲和上下文中，核心判定标准包括：

• 内部存储每处理器状态的数据结构，不再依赖单组范围内的连续处理器编号做直接寻址
• 所有涉及线程亲和性调整的逻辑，不再使用仅支持单组操作的旧版API
• 不再将跨组调用DLL导出函数的场景视为未定义行为

问题2：自启动线程并调用SetThreadGroupAffinity的DLL相关要求 #

编译flag相关要求 #

• 这类DLL不需要设置特殊的全局编译flag。Windows的处理器组兼容判定是运行时基于DLL的API调用行为做出的，和编译开关、版本声明宏没有绑定关系。只要代码中实际调用了SetThreadGroupAffinity这类具备组感知能力的接口，就会被系统判定为已适配多组场景，无需额外编译配置。

文档中“修改”的具体操作范围 #

所有适配多组运行逻辑的代码调整都属于文档提到的“修改”范畴，具体包含：

• 替换无组感知的旧版亲和API：用SetThreadGroupAffinity、GetThreadGroupAffinity替代仅能操作单组范围的SetThreadAffinityMask、GetProcessAffinityMask等旧接口
• 调整每处理器数据结构的寻址逻辑：把原来用全局处理器编号作为一维数组下标的实现，改为「处理器组编号 + 组内处理器索引」的二维寻址结构，避免跨组访问时出现索引越界、数据错配
• 补全跨组访问的线程安全逻辑：如果原有逻辑默认所有调用导出函数的线程处于同一处理器组，需要补充跨组访问全局共享数据的同步机制，避免触发竞争条件
• 无需额外的特殊配置：这类修改不要求强制将DLL内部的所有线程固定到单一处理器组，也不要求在编译时声明最低支持的Windows版本，只要代码实际适配了多组运行逻辑即可满足要求。

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