Hybrid Transactional Memory(2005)

Hybrid Transactional Memory
这篇文章的核心思想是：仅仅用硬件实现TM和仅仅用软件实现TM都是有缺陷的。HTM通常都
会对TM的大小以及执行时间进行限制，如果没有限制，则硬件的复杂度会很大。而STM最关
键的问题就是执行效率比较低。本文认为，应该像实现虚拟存储器的想法一样，由软硬件共
同实现TM。文中实现的一个原型的思想比较简单：修改一个编译器并提供一个STM库，如果
程序中的某个TM符合HTM的限制，则优先使用HTM，执行失败后可能使用HTM重试，也可能使
用STM 重试，如果不符合HTM的限制，则使用库提供的STM。设计的关键在于如何使得这两种
TM很好的相互配合。例如，如何使得HTM发现于STM的冲突？实现这个的关键思想是，给HTM
的transaction添加额外的代码，这些代码保证，如果该硬件transaction与某个软件
transaction相冲突，则这个硬件transaction被abort，然后retry。

在实验中可见：
1、BDB的例子和raytrace的例子表明，即使使用TM这种编程接口，程序员也应该仔细地构
造trans，以避免不必要的冲突。
2、raytrace的例子还表明，在HyTm的实现中，频繁地将ReadOpened升级为WriteOpened
也会带来很大的性能损失，这可能需要编译器提前判断出某个两会被写，在一开始就使用
WriteMode来打开。
3、上面的例子都展示出，一个好的CM是非常重要的。
4、在模拟的实验中，有硬件辅助HyTM的性能良好，基本强于细粒度的锁机制。纯软件的
HyTM性能不如细粒度的锁机制，但扩展性仍然良好。这是在冲突很小的情况下。
5、在冲突和重的情况下，细粒度的锁机制性能损失严重，同时，纯软件的HyTM性能在32个
thread的时候不再增长，很可能是由于CM的问题引起的。而有硬件配合的HyTM，采用
backoff机制，可扩展性非常好，接近于LogTM。

注：文章中提示，这里有一点注意，编译器应该能够优化trans中对常量的读取。就是，如果
trans需要读取某个常量，编译器可以用类似循环不变量外提的方法将这个常量在trans外
先读取到本地，然后再开始trans。这样会减少冲突。这个对于别的TM可能不是问题，但是
对于本文实现的，却会引起可扩展性的问题。
其实，编译器可以做更多的对于trans的优化，而不只是上面的常量的情况。也许这是一个
新的研究方向。就像优化循环那样，针对trans做优化。例如，还有padding的技术用于
防止一个数组不同的元素被hash函数映射到同一个orec上等。