.NET 中的线程安全集合

发布于 2024-09-04 04:34:27 字数 59 浏览 1 评论 0原文

当需要线程安全集合(例如 Set)时,现在的标准是什么? 我自己同步它,还是有一个本质上线程安全的集合?

What is the standard nowadays when one needs a thread safe collection (e.g. Set).
Do I synchronize it myself, or is there an inherently thread safe collection?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

原来分手还会想你 2024-09-11 04:34:27

.NET 4.0 Framework 在系统中引入了多个线程安全集合。 Collections.并发命名空间:

ConcurrentBag
     表示线程安全、无序的对象集合。

ConcurrentDictionary
   表示可以被多个线程同时访问的线程安全的键值对集合。

ConcurrentQueue
   表示线程安全的先进先出 (FIFO) 集合。

ConcurrentStack
   表示线程安全的后进先出 (LIFO) 集合。


.NET Framework 中的其他集合默认情况下不是线程安全的,需要为每个操作锁定:

lock (mySet)
{
    mySet.Add("Hello World");
}

The .NET 4.0 Framework introduces several thread-safe collections in the System.Collections.Concurrent Namespace:

ConcurrentBag<T>
      Represents a thread-safe, unordered collection of objects.

ConcurrentDictionary<TKey, TValue>
    Represents a thread-safe collection of key-value pairs that can be accessed by multiple threads concurrently.

ConcurrentQueue<T>
    Represents a thread-safe first in-first out (FIFO) collection.

ConcurrentStack<T>
    Represents a thread-safe last in-first out (LIFO) collection.


Other collections in the .NET Framework are not thread-safe by default and need to be locked for each operation:

lock (mySet)
{
    mySet.Add("Hello World");
}
云淡风轻 2024-09-11 04:34:27

在 .net 4.0 之前,.Net 中的大多数集合都不是线程安全的。您必须自己做一些工作来处理同步: http://msdn .microsoft.com/en-us/library/573ths2x.aspx

文章引用:

集合类可以做成线程
安全使用以下任何一项
方法:

使用以下方法创建线程安全的包装器
同步方法,并访问
专门通过该收集
包装纸。

如果该类没有
同步方法,派生自
类并实现 Synchronized
使用 SyncRoot 属性的方法。

使用锁定机制,例如
C# 中的锁定语句(SyncLock in
Visual Basic),在 SyncRoot 上
访问时的属性
收藏。

同步根属性
锁定语句

Object thisLock = new Object();
......
lock (thisLock)
{
    // Critical code section
}

在 .net 4.0 中引入了 System.Collections.Concurrent 命名空间

阻止收集
并发包
并发队列
并发词典
可订购分区程序
分区器< br>
分区程序 T

Pre .net 4.0 most collections in .Net are not thread safe. You'll have to do some work yourself to handle the synchronization: http://msdn.microsoft.com/en-us/library/573ths2x.aspx

Quote from article:

Collections classes can be made thread
safe using any of the following
methods:

Create a thread-safe wrapper using the
Synchronized method, and access the
collection exclusively through that
wrapper.

If the class does not have a
Synchronized method, derive from the
class and implement a Synchronized
method using the SyncRoot property.

Use a locking mechanism, such as the
lock statement in C# (SyncLock in
Visual Basic), on the SyncRoot
property when accessing the
collection.

Sync Root Property
Lock Statement

Object thisLock = new Object();
......
lock (thisLock)
{
    // Critical code section
}

In .net 4.0 the introduced the System.Collections.Concurrent namespace

Blocking Collection
Concurrent Bag
Concurrent Queue
Concurrent Dictionary
Ordable Partitioner
Partitioner
Partitioner T

执着的年纪 2024-09-11 04:34:27

.NET 4在System.Collections.Concurrent下提供了一组线程安全的集合

.NET 4 provides a set of thread-safe collections under System.Collections.Concurrent

流绪微梦 2024-09-11 04:34:27

除了 System.Collections.Concurrent 中非常有用的类之外​​,在大多数读取很少更改的场景(或者如果存在频繁但非并发的写入)中,一种标准技术是也适用于.Net,称为Copy-on-write< /a>.

它有几个在高并发程序中需要的属性:

  • 集合对象实例本身是不可变的(即线程安全,可以安全地枚举而无需锁定)
  • 修改可以花费尽可能多的时间,读取的性能和并发性不受影响的
  • 可以通用实现将任何非线程安全的数据结构转换为线程安全的数据结构限制

:如果有并发写入时,可能需要重试修改,因此并发写入越多,效率就越低。 (这就是工作中的乐观并发

编辑 Scott Chamberlain 的评论提醒了我还有另一个限制:如果您的数据结构很大,并且经常发生修改,则在内存消耗和所涉及的复制的 CPU 成本方面,写时复制可能会令人望而却步。

In a addition to the very useful classes in System.Collections.Concurrent, one standard technique in mostly-read-rarely-change scenarios (or if there are however frequent, but non-concurrent writes) that is also applicable to .Net is called Copy-on-write.

It has a couple of properties that are desirable in highly-concurrent programs:

  • collection object instances themselves are immutable (i.e. thread-safe, can be safely enumerated without locking)
  • modification can take as much time as it wants, performance and concurrency of reads are not affected
  • can be implemented generically to turn any data structure that is not thread-safe into one that is

Limitation: If there are concurrent writes, modifications may have to be retried, so the more concurrent writes get, the less efficient it becomes. (That's optimistic concurrency at work)

Edit Scott Chamberlain's comment reminded me that there's another limitation: If your data structures are huge, and modifications occur often, a copy-all-on-write might be prohibitive both in terms of memory consumption and the CPU cost of copying involved.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文