事务存储结构的实现_计算机论文.docVIP

事务存储结构的实现_计算机论文 事务存储结构的实现_计算机论文 摘 要 多核处理技术将成为计算机的主流技术，基于多核开发线程级并行已至关重要，事务的引入能够解决目前线程所不能完成的功能，同时能够简化编程模型，事务存储能很好地实现事务特性。本文首先介绍了TM的基本原理，接着分析了目前主流TM系统LogTM，着重于数据版本管理和冲突管理机制的实现，进而将此系统的优越性展现出来。最后对本文进行了总结和展望。 关键词 事务存储；日志事务存储；体系结构；操作系统 1 引言 随着多核处理器技术的不断更新和发展，传统的串行程序不论在效率上还是性能上都已经跟不上信息高速发展的脚步了，程序员不得不开发线程级并行以提高片上计算资源的使用效率，但也带来了新的挑战和问题。目前不同线程间的同步、对共享资源的访问等都是通过锁和信号量机制完成的。然而，这种传统的基于锁和信号量的并发系统存在明显的局限性。粗粒度的锁对大量的共享数据做了保护，但是可扩展性不好，因为即使在线程间不存在对共享数据的访问的情况下也可能会出现冲突阻塞现象；细粒度的锁虽然比粗粒度的锁扩展性能好，但由于算法设计的复杂性，普通程序员很难借助细力度的锁实现高效的应用。同时使用锁机制还会带来诸多问题，比如：死锁、优先级反转等，极大地影响了并行应用的效率和性能。 事务存储(Transactional Memory，TM)的使用是解决上述存在问题一个很好的办法[1]。通过将不同并行执行的线程事务化，用事务操作来代替锁机制能降低编程的复杂性。事务是被单线程执行的对内存进行读写的有序操作序列，其特性包括：原子性、隔离性、一致性和持久性。通常事务的执行过程为：调用事务入口函数(begin_transaction)开始执行事务，当事务执行完毕后调用提交函数(commit_transaction)开始提交工作，提交过程分为三个阶段(请求提交、开始提交和完成提交)，执行完提交后此事务也就执行完毕，从而继续执行下面的事务。但如果事务在执行或提交过程中发生冲突或者错误，则通过其特有的回滚机制 (rollback)返回到此事务入口继续执行。事务的执行流程图如图 1所示。图 1 事务执行流程 为了实现事务的这些特性，需有一个很好的TM系统来支持事务数据的版本管理(Version Management)和事务的冲突管理(Contention Management)。版本管理同时对新值(事务提交后可见)和原始的旧值(事务执行过程中发生了回滚的恢复数据)进行管理。根据数据存放方式的不同TM系统区分版本管理为：积极版本管理(Eager Version Management)和懒惰版本管理(Lazy Version Management)。积极版本管理是将新值置于目标存储区中，这样在提交时新值能够很快的得到执行，极大地降低了提交的时延；而懒惰版本管理是将原始的旧值置于目标存储区，虽然会增加提交的延时但是降低了当事务发生回滚后执行的延时。冲突管理是不同事务执行过程中对共享资源访问引发冲突而进行的冲突检测以及管理的机制。冲突管理有积极的(Eager)和懒惰的(Lazy)两种策略，如果冲突在读数据或写数据时立刻被发现而进行仲裁，这种冲突检测是积极的；如果冲突是在事务进行提交时才发现并仲裁的，这种冲突检测则是懒惰的。 目前，基于TM的硬件结构有很多种，图2中列出了目前几种流行的硬件结构根据版本管理和冲突管理而进行的分类。本文将介绍其中的一种结构——LogTM(日志事务存储)，通过对其硬件结构（参见图3）、版本管理、冲突管理的实现，展现了此结构的优越性，并给后续研究提供参考和帮助。图2 TM系统分类 2 LogTM的结构 LogTM是建立在多机系统中基于日志的TM实现，每个核都有独自的私有cache，并通过目录协议来维持数据的一致性。它采用的是积极的版本管理策略和积极的冲突管理策略。图3给出了LogTM的硬件结构，它通过增加一些寄存器和cache中的读/写位很好地完成了对事务的操作。图3 LogTM的硬件结构 (图中黑框中为其特有结构) 2.1 版本管理(Version Management) LogTM使用积极的版本管理，将新的执行数据存储在目标区域(目标地址)中，而将旧的数据存储在其它缓冲区。它通过在内存中开辟一块事务日志区域存储事务执行过程中被修改的数据(上文中提到的原始数据)和这些数据所对应的地址，新的执行数据则被保存在目标存储区(目标地址)，当执行完成提交时，这些新数据将会立即生效；当事务执行过程中或提交时发生冲突或错误需要回滚时，则通过事务日志中记录的信息恢复出事务执行前的初始状态。 刚开始创建线程时，每一个线程对应着一个日志而且为日志分配一块虚拟存储区域，并将该日志基地址写入Log Base寄存器，当旧数据需