用__builtin_cpu_supports("rtm")检测tsx支持，返回非零值表示支持rtm指令（如_xbegin），否则需回退至mutex等传统同步机制；编译必须加-mrtm，且需注意intel新cpu已弃用tsx。
如何用 __builtin_cpu_supports 检测 TSX 支持
TSX（Transactional Synchronization Extensions）不是所有 x86 CPU 都支持，必须在运行时确认。GCC/Clang 提供的 __builtin_cpu_supports 是最轻量、最安全的方式——它不触发非法指令，也不依赖 cpuid 手动解析。
关键点：字符串必须是编译期常量，且只接受 "rtm"（代表 Restricted Transactional Memory，即 TSX 的核心指令集），不能写成 "tsx" 或 "htmx"。
-
__builtin_cpu_supports("rtm")返回非零值 → 当前 CPU 支持 TSX（含_xbegin/_xend） - 返回 0 → 不支持，必须走 fallback 路径（如 mutex）
- 该函数在未启用
-mrtm编译选项时仍合法，但若代码中直接调用_xbegin()而 CPU 不支持，会触发SIGILL
_xbegin() 的返回值必须显式判断
调用 _xbegin() 后不能假设事务一定成功；它可能因缓存冲突、内存访问越界、中断、或单纯不支持而中止，此时会跳转到 fallback 标签并返回状态码（如 _XABORT_EXPLICIT、_XABORT_CAPACITY 等）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 只有
_xbegin() == _XBEGIN_STARTED才能进入事务体 - 任何其他返回值都意味着事务未启动，必须用传统同步机制重试或降级
- 漏判
_xbegin()返回值是常见崩溃原因——比如在不支持 TSX 的机器上直接执行_xend()会 SIGILL
编译时需显式启用 RTM 支持
即使 CPU 支持、代码也做了检测，若编译器没被告知“允许生成 RTM 指令”，_xbegin 等内建函数会链接失败或报错。
- GCC/Clang 必须加
-mrtm（不是-mtsx，后者不存在） - 仅检测支持与否可不加
-mrtm，但只要调用_xbegin就必须加 - Clang 还需确保目标架构为 x86_64（
-target x86_64），否则可能静默禁用 - 注意：Intel 已在 Alder Lake 及更新 CPU 上弃用 TSX（除部分服务器型号），检测通过 ≠ 实际可用，需结合
/proc/cpuinfo中的rtmflag 交叉验证
fallback 路径里别踩 mutex 重入坑
HTM 的 fallback 不是简单套个 lock 就完事。如果事务中本就持有某个 mutex，又在 fallback 里再次尝试 lock 它，就会死锁。
- fallback 逻辑应完全独立于事务体内逻辑，避免共享锁状态
- 推荐把临界区封装成纯函数，事务路径和 mutex 路径都调用它，而非在 fallback 里重复写一遍业务逻辑
- 重试次数要设上限（如
retry ），防止因持续中止导致活锁 - 事务内禁止调用可能间接触发锁的函数（如
std::cout、malloc），否则 fallback 里再 lock 就更难厘清依赖
rtm 并不等于 BIOS/OS 允许使用——有些服务器 BIOS 默认关闭 TSX，Linux 内核也可能通过 tsx=on/off 启动参数干预。所以 __builtin_cpu_supports("rtm") 为真，只是必要条件，不是充分条件。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
