ReaderWriterLockSlim 或 Lock答案

【问题标题】：ReaderWriteLockSlim or LockReaderWriterLockSlim 或 Lock
【发布时间】：2011-09-30 17:52:23
【问题描述】：

我正在使用 ConcurrentBag 在运行时存储对象。在某些时候，我需要清空包并将包内容存储到列表中。这就是我所做的：

        IList<T> list = new List<T>();

        lock (bag)
        {
            T pixel;

            while (bag.TryTake(out pixel))
            {
                list.Add(pixel);
            }
        }

我的问题是同步，据我在书中读到的锁比其他同步方法快。来源——http://www.albahari.com/threading/part2.aspx。

性能是我的第二个关注点，我想知道此时我是否可以使用 ReaderWriterLockSlim。使用 ReaderWriterLockSlim 有什么好处？原因是，我不希望此操作阻止传入请求。

如果是，我应该使用升级锁吗？

有什么想法吗？评论？

【问题讨论】：

您是否遇到了这段代码的特定性能问题，或者只是在试验一些东西？
失去锁。 ConcurrentBag 针对填充包的线程与清空包的线程相同的情况进行了高度优化。如果在您的特定用法中不是这种情况，请尝试使用队列和显式锁。

标签： c# multithreading synchronization locking readerwriterlockslim

【解决方案1】：

我不确定你为什么要使用锁。 ConcurrentBag 背后的整个想法是并发。

除非你只是想阻止其他线程在你清空袋子时拿东西或往袋子里加东西。

重新阅读您的问题，我很确定您根本不想在此处同步访问。 ConcurrentBag 允许多个线程到Take 和Add，而无需进行任何显式同步。

如果您锁定了袋子，那么在您的代码运行时，没有其他线程可以添加或删除东西。当然，假设您用锁保护对包的所有其他访问。一旦你这样做了，你就完全违背了拥有无锁并发数据结构的目的。您的数据结构已成为受锁控制的性能不佳的列表。

如果您使用读写锁，情况也是如此。您必须同步每个访问。

在这种情况下，您不需要添加任何显式同步。扔掉锁。

【讨论】：

好的，这个操作需要 0.0002 秒。我不担心性能，因为它已经足够快了。我想看看使用 RWSLIM 是否更合乎逻辑。我需要清空袋子，这就是我锁定它的原因。

【解决方案2】：

当线程将连续执行大量操作时，锁定非常有用（突发 - 低争用）

当您拥有比写锁更多的读锁时，RWSlim 非常棒（读重 - 读争用高）

当您需要多个读取器和/或写入器同时工作时，无锁非常棒（读取/写入混合 - 大量争用）

【讨论】：