我很高兴看到System.Collections.Concurrent.Net 4.0中的新名称空间,这真是太好了!我见过ConcurrentDictionary,ConcurrentQueue,ConcurrentStack,ConcurrentBag和BlockingCollection。
System.Collections.Concurrent
ConcurrentDictionary
ConcurrentQueue
ConcurrentStack
ConcurrentBag
BlockingCollection
似乎神秘失踪的一件事是ConcurrentList<T>。我是否必须自己写一个(或从网络上获取它:))?
ConcurrentList<T>
我在这里错过明显的东西吗?
我试了一下(也:在GitHub上)。我的实现存在一些问题,这里不再赘述。让我告诉您,更重要的是,我学到了什么。
首先,您将无法获得IList<T>无锁且线程安全的完整实现。特别是,除非您还忘记了O(1)随机访问(即除非您“作弊”并仅使用某种类型的链表并让索引很烂),否则随机插入和删除将 无法 工作。
IList<T>
我 想 可能是值得的是线程安全的,集有限的IList<T>:尤其是,一个将允许Add并提供随机 只读 通过索引访问(但没有Insert,RemoveAt等,还没有随机 写入 访问)。
Add
Insert
RemoveAt
这是我ConcurrentList<T>实施的目标。但是,当我在多线程方案中测试其性能时,我发现 仅同步添加到aList<T>会更快。基本上,添加到a List<T>已经快如闪电;所涉及的计算步骤的复杂性很小(增加索引并分配给数组中的元素; 的确如此 )。您将需要进行 大量 并发写入,以查看与此相关的任何类型的锁争用。即使在这种情况下,每次写入的平均性能仍然会击败更昂贵的方法,尽管在中是无锁的ConcurrentList<T>。
List<T>
如果列表的内部数组需要调整自身大小,这种情况很少见,那么您付出的代价确实很小。因此,最终,我得出结论,这是 一个 只添加ConcurrentList<T>集合类型就有意义的小众场景:当您希望 确保 在 每次调用 中添加元素的开销很低时(因此,与摊销的性能目标相对)。
它根本不像您想的那样有用。