Когда 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)к методам Getand Addметоды Lockedand RWLocked(и использовал 4 потока чтения против 1 потока записи), я не RWLockedвыдержал Locked.

Изменить : Хорошо, если бы я действительно думал, когда впервые опубликовал этот ответ, я бы понял, по крайней мере, почему вы помещаете Thread.Sleepтуда вызовы: вы пытались воспроизвести сценарий чтения, происходящего чаще, чем записи. Это просто неправильный способ сделать это. Вместо этого я хотел бы ввести дополнительные накладные расходы на ваши Addи Getметоды , чтобы создать больше шансы раздора (как Ганс предложил ), создать более читаемые потоки , чем потоки записи (для обеспечения более частых операции чтения , чем записи), и удалить Thread.Sleepвызовы от ReadThreadи WriteThread(которые на самом деле уменьшить разногласия, достигнув противоположного желаемого).

Мне нравится то, что вы сделали до сих пор. Но вот несколько проблем, которые я вижу сразу же:

1. Почему Thread.Sleepзвонки? Это просто завышение времени выполнения на постоянную величину, что искусственно приведет к сходимости результатов производительности.
2. Я также не стал бы включать создание новых Threadобъектов в код, который измеряется вашим Stopwatch. Создать такой объект нетривиально.

Я не знаю, заметите ли вы существенную разницу, когда решите две проблемы, указанные выше. Но я считаю, что их следует рассмотреть до продолжения обсуждения.

Вы получите лучшую производительность, ReaderWriterLockSlimчем простая блокировка, если заблокируете часть кода, для выполнения которой требуется больше времени. В этом случае читатели могут работать параллельно. Получение ReaderWriterLockSlimзанимает больше времени, чем ввод простого 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.

Если у вас нет многоядерного оборудования (или, по крайней мере, такого же, как ваша запланированная производственная среда), вы не получите здесь реалистичного теста.

Более разумным тестом было бы продлить срок службы заблокированных операций, поместив небольшую задержку внутри блокировки. Таким образом, вы действительно сможете противопоставить параллелизм, добавленный using, ReaderWriterLockSlimи сериализацию, подразумеваемую базовым lock().

В настоящее время время, затрачиваемое на ваши заблокированные операции, теряется в шуме, создаваемом вызовами сна, происходящими вне блокировок. Общее время в любом случае в основном связано со сном.

Вы уверены, что в вашем реальном приложении будет одинаковое количество операций чтения и записи? ReaderWriterLockSlimдействительно лучше для случая, когда у вас много читателей и относительно редко пишут. 1 поток записи по сравнению с 3 потоками чтения должны ReaderWriterLockSlimлучше продемонстрировать преимущества, но в любом случае ваш тест должен соответствовать ожидаемому шаблону доступа в реальном мире.

Я предполагаю, что это из-за того, что вы спите в ваших читательских и писательских тредах.
Ваш поток чтения имеет спящий режим 500тимс 50 мс, что составляет 25000 большую часть времени.

Когда ReaderWriterLockSlim лучше простой блокировки?

Когда у вас значительно больше операций чтения, чем записи.