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
评论