枚举并发集合探讨

作者 Jonathan Allen 译者 朱永光 发布于 2008年9月3日

领域

架构 & 设计,

语言 & 开发

主题

性能和可伸缩性 ,

.NET

标签

并行计算

.NET的并行扩展（Parallel Extensions）包括两个并发集合：堆栈和队列。其他集合类还是按照它们固有的方式工作，但是对于语义的处理依然有一些挥之不去的问题。尤其是当集合在一个线程被编辑，而在另外一个线程被枚举的时候，会发生什么呢？

对于单线程的类，答案是众所周之的，枚举器将抛出一个异常。不过对于并发类来说，在这种情况下应该设定一种规则，提供几种选择。

一种选择是，在枚举开始的时候为现存数据创建一个快照。这种方式在循环的过程中会占用更多的内存，不过快照一旦被创建，就可以被自由地锁定。这种方式下隐含的性能问题很难被预估。

不使用快照，集合还有一组保证措施提供给开发人员。它们中很多都是自相矛盾的，不过在某些条件下它们也都是适合的。

• 删除的条目总是可读
• 删除的条目不可再读
• 如果添加在集合的末尾，那么添加的条目总是可读
• 如果添加在集合的任何地方，那么添加的条目总是可读
• 添加的条目总是不可读取
• 被移动的条目，不能被读取两次
• 被移动的条目，如果是移动到集合的末尾，那么就能被读取两次
• 被移动的条目，就算是被移动到集合的开头，也总是可以读取
• 不超过N条的条目就能被读取，而N是集合的初始大小。

在给出一个选择范围后，Stephen Toub向大家征询关于并行扩展的反馈意见：

1. 鉴于在.NET中已经存在一些标准的集合类了，假如你已经具有它们的线程安全（thread-safe）版本，那么什么样的情形下，你才可以从能并发地枚举同一个被其它线程同时编辑的集合中获得好处？我们虽然对此已经有所了解，不过还是很想多听听大家的意见。
2. 假设你确实具有第一条提到的情形，那么为了让从枚举器中返回的数据是可用的，你大概需要的最小保证措施是什么？例如，对于一个字典对象如果不存在并发编辑（添加/更新/删除），你可以认为它是线程安全的，你将能在枚举过程中准确地得到字典中的内容；然而，如果存在并发访问，你再也不能得到已经不存在于字典中的内容，你可能看不到并发添加或更新的东西，也可能依然能看到那些被并发地删除的条目。
3. 如果我们确实支持在线程安全的集合上进行面向并发编辑的枚举操作，那么你希望能够从“在并发编辑上抛出异常”这样的行为中恢复之前的操作吗？
4. 最后，你期望看到的既线程安全又能实现可伸缩副本的集合中，哪个最重要？

Omer van Kloeten对于序列化，提出了一个重要的问题，

一个重要的附加功能是能够异步地转储（dump），即有时为了备份可以把内存的数据缓存到持久性存储，这就要求线程安全的枚举过程。（实际上，想一想——是否也能线程安全地序列化？这样的话什么才是默认的行为呢？）

Rick Brewster则建议我们求助于函数式编程概念。代替在外部锁定集合的方式，所有对集合的并发操作都能通过给“Lock（Action）”方法传递一个委托来执行。

这个点子就是让“Lock”方法自动地用lock/unlock这样的结构把你的回调包围起来。这种方法也不会限制你使用这些类当前已经暴露出来的原子操作。实际上，也许让Lock来获得Func而非Action更好，并且ConcurrentList类本身不真正具有任何用于get、set、enumerate的方法。使用这种方式，你就只能访问在锁定范围内的类。

查看英文原文：Enumerating Concurrent Collections

译者 朱永光 是IT自由人和环境保护者，微软最有价值专家（MVP）和MCSD。

• 更早的 >