1. 首页
  2. 文章资讯
  3. AI技术
  4. AI应用开发

从硬件事务内存（Intel TSX）到软件事务内存：并发编程范式的演进与实战

1 阅读 0 评论

从硬件事务内存（Intel TSX）到软件事务内存：并发编程范式的演进与实战

在多核时代，锁一直是并发编程的基石，但它的代价很明确：粒度难以权衡、死锁难以调试、优先级反转无法彻底避免。事务内存（Transactional Memory, TM）曾经是学术界和工业界眼中的"圣杯"——让开发者像编写单线程代码一样声明原子块，由运行时自动处理并发冲突。这场从硬件到软件的演进之旅，至今仍在塑造着系统软件的底层设计。

1. 锁的困境与事务内存的承诺

考虑一个典型的并发哈希表操作：

void hash_insert(HashTable *ht, Key key, Value val) {
    lock(&ht->lock);            // 全局锁：简单但可扩展性差
    bucket_lookup_and_insert(ht, key, val);
    unlock(&ht->lock);
}

当并发线程数超过四时，全局锁的争用会迅速拖垮性能。缩小锁粒度可以缓解，但代价是复杂度和死锁风险指数级上升。事务内存的理想模型是：

void hash_insert_tm(HashTable *ht, Key key, Value val) {
    XBEGIN();                    // 开启事务
    bucket_lookup_and_insert(ht, key, val);
    XEND();                      // 提交事务（无冲突时原子生效）
}

读集（read-set）和写集（write-set）被底层跟踪，仅在提交时检测到读写冲突才回滚重试——这正是硬件事务内存（HTM）的承诺。

2. Intel TSX 架构解析

Intel 在 Haswell 微架构（2013）中引入 TSX，包含两种接口：

HLE（Hardware Lock Elision） 通过 XACQUIRE/XRELEASE 前缀（opcode F2/F3）重写已有的 LOCK 前缀指令，向后兼容——在不支持 TSX 的 CPU 上退化为普通锁，在执行时把锁"省略"。

RTM（Restricted Transactional Memory） 提供全新指令： - XBEGIN <fallback>：进入事务，参数为失败处理的跳转地址 - XEND：提交事务 - XABORT <status>：显式中止并传入状态码 - XTEST：测试当前是否处于事务中

RTM 提供了更精细的控制，是现代软件的主流选择。

+-----------------------------------------------------------+
|                    RTM 事务状态机                          |
|                                                           |
|  Normal Execution ----XBEGIN----> 事务中（Transactional） |
|          ^                             |                  |
|          |                           XEND                 |
|          |                             |                  |
|          |                             v                  |
|     fallback <----XABORT/XBEGIN fail---                  |
+-----------------------------------------------------------+

关键约束：事务中的代码必须保证"反向兼容"——fallback 路径必须在不开启事务的情况下也能正确执行，通常通过传统的互斥锁实现。

3. 实战：基于 RTM 的无锁并发哈希表

以下使用 GCC 内建函数实现一个 RTM 并发哈希表：

#include <immintrin.h>
#include <stdatomic.h>

#define HTM_MAX_RETRIES  10
#define LOCK_SERIAL      0xFF  // 锁序列化标志

typedef struct {
    _Atomic uint64_t lock;       // 锁字（用于 fallback）
    Entry *buckets;
} RTMHashTable;

bool rtm_hash_insert(RTMHashTable *ht, uint64_t key, uint64_t val) {
    uint32_t retries = 0;

retry:
    if (retries >= HTM_MAX_RETRIES)
        goto fallback;

    // __XACQUIRE 与 RTM 配合：首先尝试 elide 锁
    uint32_t status = _xbegin();
    if (status == _XBEGIN_STARTED) {
        // 事务内：锁必须已被清除或被 elide
        if (atomic_load(&ht->lock) & LOCK_SERIAL) {
            _xabort(0xFE);  // 锁被占用，中止事务
        }
        // 执行插入操作
        bucket_insert(ht, key, val);
        _xend();
        return true;
    } else {
        // 事务失败：分析失败原因
        if (status & _XABORT_CONFLICT)
            retries++;      // 冲突：指数退避后重试
        else if (status & _XABORT_RETRY)
            retries++;      // 可重试原因再尝试
        else
            goto fallback;  // 不可重试原因直接走 fallback
        _mm_pause();
        goto retry;
    }

fallback:
    // 传统加锁路径
    while (atomic_fetch_or(&ht->lock, LOCK_SERIAL) & LOCK_SERIAL)
        _mm_pause();
    bucket_insert(ht, key, val);
    atomic_store(&ht->lock, 0);
    return true;
}

关键设计要点：

  • 冲突回退策略：并非所有中止都意味着"不可重试"。_XABORT_RETRY 标识因缓存逐出或中断导致的中止，值得重试；但事务容量超限（capacity abort）应直接降落到 fallback 锁路径。
  • _mm_pause()：自旋等待时使用 PAUSE 指令降低功耗，Skylake 后 PAUSE 延迟约 142 周期，远超早期的 ~10 周期。
  • 锁 elision 语义：事务期间直接访问锁保护的内存，提交时若锁被其他线程获取则触发冲突中止。

4. 事务中止的深层因素

即使逻辑上没有两个线程访问同一地址，事务仍可能中止。在 Intel 平台上，常见原因包括：

  1. 容量中止（Capacity Abort）：L1 缓存（32KB）无法容纳写集或读集。x86 的事务内存依赖 L1d cache 做写集跟踪（write-set tracking via modified cache lines），任何缓存行被逐出都会导致中止。
  2. 隐式事务事件：CPUID、IRET、RSM、系统调用、中断、上下文切换、页表修改等事务内非法指令都会触发中止。
  3. TSX 虚拟ization：VM 退出（VMEXIT）也会中止事务。在某些虚拟机监控器配置下，TSX 会被强制禁用。
  4. 跨核指令流：跨核 SLAT 重定位等操作触发中止。

这意味着事务内的代码必须短小、确定，不能包含任何 I/O、系统调用或函数调用（除非链接器确保其内联）。

5. Intel TSX 的兴衰与复活

TSX 的工程实践远比理论复杂。2014 年 Intel 发现 Haswell/Broadwell 存在硬件级 TSX bug（触发条件复杂但可复现），发布了微码更新全局禁用 TSX。这件事给开发者敲响了警钟：不能将 RTM 作为唯一正确路径。

直到 Skylake-SP 和 Ice Lake，TSX 才在某些 SKU 上重新启用，但服务器领域的态度分化明显——Intel 在 Ice Lake Xeon（2021）上又引入了 TSX_FORCE_ABORT MSR 强制在某些型号禁用，Cascade Lake 微码更新也默认禁用了 TSX。

现状（2025）： - 消费级（Core i9-13900K+）：TSX 因微码更新默认禁用，但可通过 BIOS TSX_CTRL re-enable - 服务器级（Sapphire Rapids+）：Intel TAA（TSX Asynchronous Abort）漏洞后，TSX 在多数型号中处于禁用状态 - Intel 的替代方案：引入 Intel TME（Total Memory Encryption）与后续的 TME-MK，TSX 不再是主流方向

尽管如此，TSX 在代码教学、研究、老平台和新平台的可用 SKU 中仍有价值。理解 HTM 对理解软件事务内存（STM）至关重要。

6. 软件事务内存（STM）的崛起

当硬件不再可靠，软件方案接管了局面。STM 通过手动跟踪读写集 + 原子操作实现事务语义。

6.1 TL2 算法

TL2 是经典的 OCC（Optimistic Concurrency Control）风格 STM：

// 全局版本时钟
static atomic_uint global_clock = 0;

typedef struct {
    atomic_uint *word_version;
    atomic_uint *lock_table;
} STMContext;

// 事务结构
typedef struct {
    uint snapshot;               // 事务开始时的 global_clock
    uint *read_set;              // {addr, version_at_read} 数组
    uint writeb_set_count;
    WriteEntry *write_set;       // {addr, val, version_at_write} 数组
    uint read_stamp;             // 提交时记录的 clock
} Tx;

void stm_read(Tx *tx, atomic_uint *addr) {
    uint val = atomic_load(addr);
    uint ver = get_word_version(addr);
    if (ver > tx->snapshot || is_locked(addr))
        abort_transaction(tx);
    append_read_set(tx, addr, ver);
    return val;
}

bool stm_commit(Tx *tx) {
    // Phase 1: 锁定 write set（按地址顺序防死锁）
    sort_write_set(tx);
    for each entry in tx->write_set:
        if (!try_lock(entry->addr))
            goto release_and_fail;

    // Phase 2: 内存屏障 + 快照验证
    uint stamp = atomic_fetch_add(&global_clock, 1) + 1;
    smp_mb();

    // Phase 3: 验证 read set
    for each (addr, ver) in tx->read_set:
        if (get_version(addr) > tx->snapshot || is_locked_but_not_by_me(addr))
            goto release_and_fail;

    // Phase 4: 写入并解锁
    for each entry in tx->write_set:
        atomic_store(entry->addr, entry->val);
        set_version(entry->addr, stamp);  // 更新版本

    tx->read_stamp = stamp;
    release_all_locks(tx);
    return true;

release_and_fail:
    release_all_locks(tx);
    return false;
}

TL2 的核心优势：写操作通过版本化写缓冲避免了首读不一致；提交采用 2-phase lock + 全局版本递增保证线性一致性。

其劣势：全局版本时钟在竞争场景下成为瓶颈；每个事务的 read set 验证开销为 O(nreads)。

6.2 NOrec：消除 Read Set 验证

Pandis 等人提出的 NOrec（No-records）颠覆了传统设计：

核心思想：事务的"原子性"不再通过逐一验证每个读记录来维护，而是通过一个原子值（全局锁/哨兵值）统一保证：

bool TXN_START(Tx *tx) {
    tx->ro = false;
    tx->start_ts = atomic_load(&g_timestamp);
    return true;
}

uint64_t TXN_READ(Tx *tx, uint64_t *addr) {
    uint64_t val = *addr;
    // 写集查找：如果已在本地写集中，返回上次写值
    for (int i = tx->wr_used - 1; i >= 0; i--) {
        if (tx->write_set[i].addr == addr)
            return tx->write_set[i].val;
    }
    return val;  // 直接读"最新值"
}

bool TXN_COMMIT(Tx *tx) {
    if (tx->wr_used == 0) return true;  // 只读事务

    // 获取提交令牌（类似全局序列号）
    uint64_t end_ts = 1;
    uint64_t prior = atomic_fetch_val(&g_seq, &end_ts); // CAS 操作

    // 验证：检查写集中每个地址的当前最新值是否与读时一致
    for (int i = 0; i < tx->wr_used; i++) {
        uint64_t *addr = tx->write_set[i].addr;
        if (*addr != tx->write_set[i].old_val && tx->write_set[i].old_val != tx->start_ts)
            return false;  // 验证失败
    }

    // 原子写入：利用 CAS 确保写入序列号
    for (int i = 0; i < tx->wr_used; i++) {
        atomic_release_store(addr, end_ts);  // 写后释放序列号
    }
    return true;
}

NOrec 的关键洞察：在读多写少场景中，read set 验证的时间浪费远比 commit 阶段的全局验证严重。NOrec 用 last-write-wins + 验证读集改为 commit 时的轻量级检查，吞吐大幅提升。

性能对比（典型 workload：90% 读 / 10% 写，32 线程）： - TL2: ~120K txn/s - NOrec: ~280K txn/s - 全局锁: ~180K txn/s

NOrec 在适当场景下能超越全局锁，这颠覆了"细粒度必然更慢"的刻板印象。

6.3 RingSTM 与自适应 TM

最新的 STM 实现（RingSTM, E-STM、TinySTM）引入了： - 自适应粒度：根据当前争用程度自动降级为锁升级 - 无锁提交（Lock-free Commit）：消除 commit 阶段的中心瓶颈 - 锁耦合（Lock coupling）：减少 commit 阶段的临界区

7. 混合事务内存（Hybrid TM）：HTM 与 STM 的联姻

最具实用价值的设计是 HTM/STM hybrid（混合事务内存），其核心逻辑：

路径 1：尝试 HTM（快速路径）
    XBEGIN()
    // 执行事务体
    XEND()
    return SUCCESS

路径 2：HTM 不可用或失败（fallback 到 STM）
    fallback_to_stm(transaction_body, args)

GCC/Clang 的自带 TM 支持（-fgnu-tm）会自动生成这种模式：

__attribute__((transaction_safe))
void atomic_update(Node *n, int v) {
    n->value += v;
    n->version++;
}

void tm_update(Node *n, int v) {
    __transaction_relaxed {      // relaxed = 不使用强内存序
        atomic_update(n, v);
    }
}

编译器展开时会生成：

tm_update:
    call    _ITM_beginTransaction   ; RTM 尝试
    test    %eax, %eax
    jz      .Lfallback_stm
    ; 内联事务体
    call    _ITM_commitTransaction
    ret
.Lfallback_stm:
    call    _ITM_RU1               ; STM 读（调用 STM 读记录）
    call    _ITM_WU1               ; STM 写（调用 STM 写记录）
    ; ... 完整 STM 流程
    call    _ITM_commitTransaction_STM

关键：事务中的函数必须标记为 transaction_safe，否则编译器会自动触发中止或走 fallback 路径。这种约束对大型代码库是重大工程挑战。

GCC TM 的真实状态：LLVM/GNU TM 曾被寄望于成为 C/C++ TM 标准的基础，但由于 C++ TM 提案（N4338、N4514、P0099R1）长期处于实验阶段，Clang/GNU C++ TM 移除讨论已在进行。目前仅 GCC C TM 在有限平台可用。

8. 生产环境中的事务内存实战

8.1 数据库内部

PostgreSQL、MySQL 的 InnoDB 存储引擎都不直接使用 TM，但 SSTable/LSM-Tree 结构的存储引擎（RocksDB、WiredTiger、Bluestore）广泛使用细粒度锁+内存序组合实现了类似 TM 的原子性保证。RocksDB 的 SuperVersion 更新采用读写锁+引用计数，本质是对 TM 语义的手动实现。

8.2 内存数据结构

Java 的 ConcurrentSkipListMap 在 JDK 1.6+ 的实现中使用了与 TM 类似的乐观更新策略——先定位，后 CAS 插入，冲突时重试。这种模式本质是单字 TM。

C++ 的 std::experimental::parallelism v2 中的 concurrent_hash_map（Intel TBB）则使用细粒度分片锁，但在其内部实现了 lock-free 读取 + 乐观写入的混合策略，在低争用下接近 HTM 性能。

8.3 文件系统

NOVA（UCSD, 2016）持久内存文件系统引入了轻量级事务（NVTM），用 64 位版本号+PMDK libpmemobj 的事务 API 实现原子元数据更新。不是传统 STM/NVM TM，但思想相通。

9. 未来展望

虽然 Intel TSX 在服务器端前景暗淡，但 TM 的核心思想正在多个方向演进：

  1. ARM TME（Transactional Memory Extension）：ARM v9.2-A 引入。与 Intel TSX 类似但受限更多（仅 100KB 写集），白皮书 "ARM Architecture Reference Manual for A-profile" 中 ARM 持保守态度。截至 2025，尚无消费级 ARM CPU 的 TME 实测可用性报告。
  2. CXL 3.0 全局内存池：通过硬件级别的访问协调实现"事务性内存访问"。CXL.cache 协议中的 D2H 隐式跟踪天然支持部分 HTM 语义。
  3. RISC-V SSTI：RISC-V 事务内存扩展提案（2024）仍在讨论中，侧重轻量级 lockstep。
  4. 软件 TM 的复兴：随着内存延迟持续降低和原子操作改进，NOrec 族算法在 128+ 核机器上展现出比锁高一个数量级的吞吐，已在 DBx1000、FOEDUS 等研究中验证。
  5. 持久内存 TM：结合 PMDK libpmemobj 的持久事务（recoverable transaction） 将 ACID 中的 D（Durability）与 TM 结合，为 crash-safe 原子操作提供基础设施。

10. 总结

硬件事务内存（Intel TSX）是一颗流星——从 Haswell 亮相，经历了 bug 禁用、微码取消、生态萎缩，但它留下的思想遗产丰富了整个并发编程工具链。软件事务内存（TL2 → NOrec → RingSTM 的工程优化）证明了"乐观原子性"在正确场景下的卓越性能。混合 TM 范式为我们指明了未来：将 HTM 作为快速路径，STM 作为兜底，在硬件不可靠的世界中提供确定性的原子保证。

理解这场从硬件到软件的演进，不仅让我们更好地选择并发方案，更让我们理解并发计算中"乐观"与"悲观"的永恒博弈。

点赞(0) 打赏
Rust内存安全与所有权系统：从理论到生产级工程的深度实战
Rust内存安全与所有权系统：从理论到生产级工程的深度实战
Python 自由线程革命：从 GIL 到 PEP 703 —— CPython 并发模型的范式重构与工程实践
Python 自由线程革命：从 GIL 到 PEP 703 —— CPython 并发模型的范式重构与工程实践
从硬件事务内存（Intel TSX）到软件事务内存：并发编程范式的演进与实战
从硬件事务内存（Intel TSX）到软件事务内存：并发编程范式的演进与实战
Linux 内存屏障与处理器内存模型深度实战：从 x86-TSO 到 ARM64 弱序性
Linux 内存屏障与处理器内存模型深度实战：从 x86-TSO 到 ARM64 弱序性

评论列表 共有 0 条评论

暂无评论
立即
投稿

微信公众账号

微信扫一扫加关注

 发表
评论 返回
顶部