什么时候ReaderWriterLockSlim比简单的锁好？

我用这段代码在ReaderWriterLock上做了一个非常愚蠢的基准测试，其中读取发生的频率比写入高4倍：

class Program
{
    static void Main()
    {
        ISynchro[] test = { new Locked(), new RWLocked() };

        Stopwatch sw = new Stopwatch();

        foreach ( var isynchro in test )
        {
            sw.Reset();
            sw.Start();
            Thread w1 = new Thread( new ParameterizedThreadStart( WriteThread ) );
            w1.Start( isynchro );

            Thread w2 = new Thread( new ParameterizedThreadStart( WriteThread ) );
            w2.Start( isynchro );

            Thread r1 = new Thread( new ParameterizedThreadStart( ReadThread ) );
            r1.Start( isynchro );

            Thread r2 = new Thread( new ParameterizedThreadStart( ReadThread ) );
            r2.Start( isynchro );

            w1.Join();
            w2.Join();
            r1.Join();
            r2.Join();
            sw.Stop();

            Console.WriteLine( isynchro.ToString() + ": " + sw.ElapsedMilliseconds.ToString() + "ms." );
        }

        Console.WriteLine( "End" );
        Console.ReadKey( true );
    }

    static void ReadThread(Object o)
    {
        ISynchro synchro = (ISynchro)o;

        for ( int i = 0; i < 500; i++ )
        {
            Int32? value = synchro.Get( i );
            Thread.Sleep( 50 );
        }
    }

    static void WriteThread( Object o )
    {
        ISynchro synchro = (ISynchro)o;

        for ( int i = 0; i < 125; i++ )
        {
            synchro.Add( i );
            Thread.Sleep( 200 );
        }
    }

}

interface ISynchro
{
    void Add( Int32 value );
    Int32? Get( Int32 index );
}

class Locked:List<Int32>, ISynchro
{
    readonly Object locker = new object();

    #region ISynchro Members

    public new void Add( int value )
    {
        lock ( locker ) 
            base.Add( value );
    }

    public int? Get( int index )
    {
        lock ( locker )
        {
            if ( this.Count <= index )
                return null;
            return this[ index ];
        }
    }

    #endregion
    public override string ToString()
    {
        return "Locked";
    }
}

class RWLocked : List<Int32>, ISynchro
{
    ReaderWriterLockSlim locker = new ReaderWriterLockSlim();

    #region ISynchro Members

    public new void Add( int value )
    {
        try
        {
            locker.EnterWriteLock();
            base.Add( value );
        }
        finally
        {
            locker.ExitWriteLock();
        }
    }

    public int? Get( int index )
    {
        try
        {
            locker.EnterReadLock();
            if ( this.Count <= index )
                return null;
            return this[ index ];
        }
        finally
        {
            locker.ExitReadLock();
        }
    }

    #endregion

    public override string ToString()
    {
        return "RW Locked";
    }
}

但是我发现两者的执行方式大致相同：

Locked: 25003ms.
RW Locked: 25002ms.
End

即使使读取的频率比写入的频率高20倍，性能仍然（几乎）相同。

我在这里做错什么了吗？

亲切的问候。

在您的示例中，睡眠意味着通常没有争用。无竞争的锁非常快。为此，您需要一个竞争锁。如果该争用中存在写操作，则它们应该大致相同（lock甚至可能更快）-但是如果大多数是读操作（很少有写争用），则我希望ReaderWriterLockSlim锁的性能优于lock。

就我个人而言，我更喜欢在这里使用引用交换的另一种策略-因此读操作始终可以在不进行检查/锁定/等操作的情况下进行。写操作将其更改为克隆副本，然后用于Interlocked.CompareExchange交换引用（如果有另一个线程，则重新应用其更改）在此期间对参考进行了更改）。

我自己的测试表明，ReaderWriterLockSlim其开销是正常值的5倍lock。这意味着RWLS要胜过普通的旧锁，通常会发生以下情况。

• 读者人数大大超过了作家。
• 锁必须保持足够长的时间才能克服额外的开销。

在大多数实际应用中，这两个条件不足以克服额外的开销。具体来说，在您的代码中，锁的保留时间很短，以至于锁开销可能是主要因素。如果要Thread.Sleep在锁中移动这些呼叫，则可能会得到不同的结果。

该程序没有争用。Get和Add方法在几纳秒内执行。多个线程在准确的时间命中那些方法的几率很小。

在其中放置一个Thread.Sleep（1）调用，并从线程中删除睡眠以查看区别。

编辑2：只需删除Thread.Sleep来自ReadThread和的电话WriteThread，我就看到了Locked表现出色RWLocked。我相信汉斯会在这里伤到头。您的方法太快，无法引起竞争。当我加入Thread.Sleep(1)到Get和Add的方法Locked和RWLocked（和使用4读出针对1个写入线程的线程），RWLocked击败裤子的Locked。

编辑：好的，如果我实际上是想，当我第一次张贴了这个答案，我就已经至少实现了，为什么你把Thread.Sleep在那里呼叫：您试图重现的读比写更经常发生的情况。这不是正确的方法。相反，我会给您Add和Get方法增加额外的开销，以产生更大的争用机会（如Hans所建议），创建比写入线程更多的读取线程（以确保读取次数比写入线程更多），并删除Thread.Sleep来自ReadThread和的调用WriteThread（实际上减少竞争，实现您想要的目标）。

我喜欢你到目前为止所做的。但是，我立即看到了一些问题：

1. 为什么要Thread.Sleep打电话？这些只是使您的执行时间膨胀了一定的数量，这将人为地使性能结果收敛。
2. 我也不会Thread在您的衡量的代码中包括新对象的创建Stopwatch。那不是要创建的琐碎对象。

解决以上两个问题后，您是否会发现明显的不同，我不知道。但是我认为应该在讨论继续之前解决它们。

ReaderWriterLockSlim如果您锁定需要较长时间执行的部分代码，则与简单锁定相比，您将获得更好的性能。在这种情况下，读者可以并行工作。获得aReaderWriterLockSlim比输入简单的时间要多Monitor。检查我的ReaderWriterLockTiny实现是否有读者-作家锁，它比简单的锁语句还要快，并提供了读者-作家功能：http : //i255.wordpress.com/2013/10/05/fast-readerwriterlock-for-net/

查看本文：http : //blogs.msdn.com/b/pedram/archive/2007/10/07/a-performance-comparison-of-readerwriterlockslim-with-readerwriterlock.aspx

您的睡眠时间可能足够长，以至于您在统计上无法锁定/解锁。

毫无争议的锁需要花费微秒级的时间，因此您对的调用将使您的执行时间相形见Sleep。

除非您具有多核硬件（或至少与计划的生产环境相同），否则您将无法在这里进行实际测试。

一个更明智的测试是通过在锁内部放置短暂的延迟来延长锁操作的寿命。这样一来，您实际上应该能够将使用添加的并行性ReaderWriterLockSlim与basic隐含的序列化进行对比lock()。

当前，锁定操作所花费的时间因锁定之外发生的Sleep调用所产生的噪音而丢失。两种情况下的总时间大部分与睡眠有关。

您确定您的真实应用程序具有相同数量的读取和写入吗？ ReaderWriterLockSlim如果您有许多读者和相对较少的作家，那真的更好。1个写程序线程与3个读程序线程应该ReaderWriterLockSlim更好地证明好处，但是在任何情况下，您的测试都应符合预期的实际访问模式。

我猜这是因为您的读取器和写入器线程处于睡眠状态。
您的读取线程有500tims 50ms睡眠，这是大多数情况下的25000睡眠

什么时候ReaderWriterLockSlim比简单的锁好？

当您的读取次数多于写入次数时。