多核环境下的transactional memory小结

《多核环境下的transactional memory小结》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、多核环境下的TransactionalMemory小结共享存储的多核处理器的出现创造了巨大的机遇去开发线程级的并行性。然而，在大多数的应用中，线程的并行执行需要实行同步或按序机制以访问共享的数据。传统的多线程程序设计模型常提供一个低层的原语集，如锁（locks），来保证互斥；一个或多个锁的所有权可以保护共享数据的访问。锁机制使用复杂，并且容易出错——特别当程序员在使用细粒度的锁机制以避免死锁或在高并行硬件上取得更好的可伸缩性。TransactionalMemory（TM）通过抽象与共享数据的并行访问相关的复杂性来解决上述问题，被人们认为是一种具有很好的发展前景机制。[1]通过利用TM，多线

2、程可以同步地原子访问共享存储单元，所以某个特定线程的所有访问在所谓的原子事务域中，要么都成功或都失败。TM把数据库中事务的概念引入计算机体系结构中，然而它与标准数据库的事务的区别是：它的主要目的是解决共享存储多处理芯片上的并发性问题。事务以原子执行单元替代锁机制，因此程序员可以只要关注在哪里需要用原子性，而不需要关心实现原子性的机制。假设在乐观的情况下，事务不会执行冲突的存储访问，那么典型的TM将实现事务的并行运行。“冲突”是指时序上的违反。如，一个当前事务中的load（read）操作未能使用一个前一事务的store（write）操作的结果。如果事务无冲突，这种乐观主义是有回报的。事务不需

3、要竞争通常的互斥锁来更新数据。在许多实现中，一个做只读访问共享数据的事务允许所有数据保留在核的数据缓存中（共享模式），有助于伸缩性。然而，如果事务尝试进行冲突的访问，这种乐观主义就变得得不偿失。TM必须放弃冲突事务中的某个事务所做的工作，保证在被放弃事务重执行前，它们产生的副作用对其他进程是不可见的。TM检测冲突和抑制被放弃事务的副作用的机制将是在本文所讨论的实现技术和案例分析所关注的。与TM比较，锁机制是保守的。使用互斥锁，只有一个进程能在一个时刻拥有一个锁，而在TM实现中，有多个进程可以同时访问一个临界区。由于实际的冲突在许多程序中是罕见的，因此乐观的TM方法作为未来的程序设计模型将会

4、更具意义。TM对于锁机制具有以下优点：lTM为并行程序编写提供高层次的抽象，使程序员集中精力在算法上而非复杂的机制如锁机制。lTM在伸缩性和实现的工作量上提供了平衡。尽管利用细粒度的锁机制可以很好的扩展，但是设计起来非常难。lTM是固有的无死锁。活锁可能是一个问题，但解决起来要比死锁容易。l作为附带的好处，TM提供失效的原子性。当然，TM不是没有缺点：l像许多高级的程序设计抽象化一样，一个设计仔细、使用低级原语的算法可以比TM的算法性能更好。l还有许多关于如何将TM呈现给程序员的问题——如提供怎样的抽象化以及开发什么样的性能协调和调试工具。本文主要总结了TM以下的四部分内容：TM的基本概念

5、；怎样实现TM，分别从硬件和软件实现的角度解读；实例分析两个基于硬件的TM，TCC和LogTM；最后是TM亟待解决的问题。TM的基本概念一个事务是一个指令序列，包括对存储的读和写，它们可能完全执行（提交）或无效（中止）。当一个事务提交时，它所有的写变成可见，其他事务可以使用这些值。当一个事务中止时，系统就丢弃它所有的推测写（speculativewrites）。为了支持事务执行，TM系统需要data-versioning机制来记录推测写。系统在事务中止时，应该丢弃其推测状态（speculativestate），反之，在成功提交时，应该更新全局状态（globalstate）。实现datave

6、rsioning的两个常见的方法是undolog或bufferedupdates。在使用undolog时，事务直接更新存储单元，同时记录下必要的信息以防在事务中止时撤销更新。相反，采用bufferedupdates时，将推测状态保存在transaction-privatebuffer中直至提交。如果提交成功，buffer丢弃store指令前的原始值并提交事务的speculativestores到存储中。TM系统可以通过执行一个中止指令显式地中止事务，或者由于并行事务的数据冲突而隐式中止事务。与冲突相关的两个问题是：检测（detection）和处理（resolution）。为了检测和处理冲突

7、，每一个运行的事务通常关联一个读集和一个写集。在事务中，每一个事务型的load操作将内存地址加到读集中，同样每一个store指令将内存地址和值加到写集中。冲突检测有eager或lazy两种模式。Eager模式检查每一个读和写看是否与另一个事务有冲突的操作。它需要一个事务的读集和写集对系统中其他所有的事务都是可见的。而在lazy模式中，事务等待直到提交时，才检查它的读写集与其他事务的写集是否有冲突。不同的TM系统检测冲突的