微软对软件内存事务的试验已告终止

阅读数:2215 2010 年 5 月 31 日

话题:.NET语言 & 开发架构

Dana Groff 宣布,微软对.NET 框架上软件内存事务(software transactional memory,简称 STM.NET)的试验已告终止。这个研究项目始于 2008 年,被用于在处理并发问题时代替显式锁。

理论上 STM 和数据库事务很相似。理想情况下,多个线程不能同时访问同一块数据,脏读将不复存在,死锁则会被自动监测和处 理。然而这也带来了和数据库事务同样的问题,比如乐观锁还是悲观锁,锁的粒度以及对性能的影响。

相对于其它软件,数据库在数据的组织形式上具有优势。数据库中的行是原子单位,可以被当作一个整体进行加锁,读取和修改。并且由于每一行都被存储在固定的 位置,使得锁升级这样的技术得以实现,以避免过多细粒度锁。而在其它软件中,对象需要通过指针链来找到根对象,这导致语义分组无法使用,并引发这样的问 题:“在这种情况下,原子单位是什么?”

早在一月,微软最知名的并行与并发编程研究员 Joe Duffy,就在他的内存事务简要回顾中谈到了他对 STM 开始失望的四个原因。

第一个原因是 I/O 问题。大多数的 I/O 访问机制天生就是非事务性的,而且随着分布式计算的流行,这些问题更加不可避免。Joe Duffy 指的不仅是文件访问,还包括日志、web service 调用、用户交互以及平台间互操作。他还说到:

这个问题最终归结为:今后的趋势会是事务性的,还是非事务性的? 继续大力推广事务是否可以取得成功,本质上取 决于这个问题的答案。我们曾将支持事务的 NTFS 和注册表添加到 Vista,那时候这个问题的答案似乎是“事务性”。但是(目前)这个趋势却在急剧放缓。

第二个问题是关于原子性强弱的选择。简单来说就是,你要求事务性对象只能通过事务进行读写,还是把决定权交给开发人员。前一种方式在程序的事务性部分和非 实物性部分共享数据时会遇到麻烦,而后一种则非常容易引发错误。

第三个原因是边界问题。就像我刚才说的,一般的软件不像数据库那样有着清晰的边界。对于原子单位的定义可能会随着时间而改变。

我仍然清晰的记得那天,就好像是昨天一样。那是一个周项目例会,讨论项目的状况、未来、遇到的问题等等。一个暑期实习大学生喝着咖啡,用 TM 做着一些探索 工作,而我则喝着茶。某个实习生不经意的言语,指出了(系统的)一个毁灭性的缺陷,足以威胁到我们正在构建的(也是当时业界普遍使用的)TM 模型。这个问 题实际上已经存在一年多了,但我们却一直没发现。这就是哪种让我感到害怕,并使我相信正规计算机科学的时刻。

事务 Tx0 将 itIsOwned 设为 true 并提交,而在提交后 Tx0 将会在 TM 的范围外使用任何已被声明的状态(在这里指的是变量 x 所指向的对象)。同 一时刻,另一个事务 Tx1 乐观的读取 itIsOwned 值并得到 false,因此继续使用 x。对于实时更新的系统,这将允许这个事务(Tx1)无限制的任 意修改 x 的状态。当然在本例中由于 isItOwned 被修改为 true,Tx1 将会被回滚。但这已经太晚了:另一个在事务外使用 x 的线程将会看到 x 的状态 在不停的改变,从这时起谁也无法知道将会发生什么。这是一个在任何弱原子性、实时更新 TM 中都存在的缺陷。

这个例子并不是人为设计的,在很多情况下都会发生类似的事情。我们第一次发现这个问题的情形是,当一个事务从链表中移除结点时,另一个事务正在反转这个链 表。如果前一个线程相信它”拥有”这个被移除的结点,因为就是它自己将这个结点移除的,那么将得到不可预期的结果。

最后一个原因是 STM 缺少实际的成功案例,他写道:

我们一直在苦苦寻找杀手级的 TM 应用。当然将范围仅放在 TM 上不太公平,因为整个业界仍在寻找杀手级的并发应用。但后来我们发现的成功案例越多,我对今后 5 年内杀手级并发应用需要 TM 的信心就越少。对于大多数自然隔离的程序,例如那些处境尴尬的并行图像处理程序,如果有任何共享数据,那基本上就是有问题 了。

与其他很多微软研究项目一样,STM.NET 的代码和示例已经被撤下,论坛也将于近期关闭,只剩下STM 编程手册与我们同在。

查看英文原文:Microsoft’s Experiments with Software Transactional Memory Have Ended