Наскільки дорого коштує заява про блокування?

Я експериментував із багатопотоковою та паралельною обробкою, і мені знадобився лічильник, щоб зробити базовий підрахунок та статистичний аналіз швидкості обробки. Щоб уникнути проблем із одночасним використанням мого класу, я використав оператор блокування приватної змінної у своєму класі:

private object mutex = new object();

public void Count(int amount)
{
 lock(mutex)
 {
  done += amount;
 }
}

Але мені було цікаво ... наскільки дорого стоїть блокування змінної? Які негативні наслідки для продуктивності?

Ось стаття, яка йде у вартість. Коротка відповідь - 50н.

Технічна відповідь полягає в тому, що це неможливо кількісно оцінити, це сильно залежить від стану буферів для запису оперативної пам’яті процесора та того, скільки даних, які зібрав префетер, потрібно викинути та перечитати. Які обидва є недетермінованими. Я використовую 150 циклів процесора як наближення до конверту, що дозволяє уникнути великих розчарувань.

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

Щоб отримати важке число, вам доведеться виміряти. Visual Studio має гладкий аналізатор паралельності, доступний як розширення.

Подальше читання:

Я хотів би представити кілька моїх статей, які цікавляться загальними примітивами синхронізації, і вони копаються у поведінці, властивостях та витратах оператора замкнення C #, залежно від різних сценаріїв та кількості потоків. Це спеціально цікавить періоди витрачання процесора та пропускну здатність, щоб зрозуміти, яку кількість роботи можна просунути в декількох сценаріях:

https://www.codeproject.com/Articles/1236238/Unified-Concurrency-I-Introduction https://www.codeproject.com/Articles/1237518/Unified-Concurrency-II-benchmarking-methodologies https: // www. codeproject.com/Articles/1242156/Unified-Concurrency-III-cross-benchmarking

Оригінальна відповідь:

О Боже!

Здається, що правильна відповідь, позначена тут як ВІДПОВІСТЬ, по суті невірна! Я хотів би попросити автора відповіді з повагою прочитати пов'язану статтю до кінця. стаття

Автор статті з статті 2003 р. Проводив вимірювання лише на машині Dual Core, і в першому випадку вимірювання він вимірював блокування лише однією ниткою, і результат становив близько 50н за доступ до блокування.

Це нічого не говорить про замок в одночасному середовищі. Отже, ми маємо продовжувати читати статтю, і у другій половині автор вимірював сценарій блокування двома та трьома потоками, що наближається до рівнів одночасності сучасних процесорів.

Так автор каже, що з двома потоками на Dual Core, блоки коштують 120ns, а з 3-х потоків - це 180ns. Таким чином, здається, це чітко залежить від кількості потоків, що одночасно отримують доступ до блокування.

Так що це просто, це не 50 нс, якщо це не єдина нитка, де замок стає марним.

Іншим питанням для розгляду є те, що він вимірюється як середній час !

Якби час ітерацій було виміряно, було б навіть час від 1 мс до 20 мс, просто тому, що більшість було швидко, але мало потоків будуть чекати процесорів час і матимуть навіть затримки в мілісекундах.

Це погана новина для будь-яких програм, які вимагають високої пропускної здатності та низької затримки.

І останнє питання для розгляду полягає в тому, що всередині замка можуть бути повільніші операції, і дуже часто це відбувається. Чим довше блок коду виконується всередині блокування, тим вища суперечка і затримки піднімаються на висоту.

Зауважте, що вже минуло десятиліття вже з 2003 року, що мало поколінь процесорів, призначених спеціально для одночасного запуску, і блокування значно погіршує їх продуктивність.

Це не відповідає вашому запиту щодо продуктивності, але можу сказати, що .NET Framework пропонує Interlocked.Addметод, який дозволить вам додати amountсвій doneчлен до свого учасника, не замикаючись вручну на іншому об'єкті.

lock (Monitor.Enter / Exit) - це дуже дешево, дешевше, ніж такі альтернативи, як Waithandle або Mutex.

Але що робити, якщо це було (трохи) повільно, ви б швидше мали швидку програму з неправильними результатами?

Вартість замка в тісному циклі, порівняно з альтернативою без блокування, величезна. Ви можете дозволити собі циклічну роботу багато разів і все ще бути більш ефективною, ніж замок. Ось чому заблокувати безкоштовні черги настільки ефективні.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace LockPerformanceConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            var stopwatch = new Stopwatch();
            const int LoopCount = (int) (100 * 1e6);
            int counter = 0;

            for (int repetition = 0; repetition < 5; repetition++)
            {
                stopwatch.Reset();
                stopwatch.Start();
                for (int i = 0; i < LoopCount; i++)
                    lock (stopwatch)
                        counter = i;
                stopwatch.Stop();
                Console.WriteLine("With lock: {0}", stopwatch.ElapsedMilliseconds);

                stopwatch.Reset();
                stopwatch.Start();
                for (int i = 0; i < LoopCount; i++)
                    counter = i;
                stopwatch.Stop();
                Console.WriteLine("Without lock: {0}", stopwatch.ElapsedMilliseconds);
            }

            Console.ReadKey();
        }
    }
}

Вихід:

With lock: 2013
Without lock: 211
With lock: 2002
Without lock: 210
With lock: 1989
Without lock: 210
With lock: 1987
Without lock: 207
With lock: 1988
Without lock: 208

Існує кілька різних способів визначення "вартості". Є фактичні витрати на отримання та звільнення замка; як пише Джейк, це незначно, якщо ця операція не проводиться мільйони разів.

Більш актуальним є вплив, який це має на потік виконання. Цей код можна вводити одночасно лише одним потоком. Якщо у вас є 5 потоків, що виконують цю операцію на регулярній основі, 4 з них в кінцевому підсумку очікують звільнення блокування, а потім буде першим потоком, який планується ввести цей фрагмент коду після звільнення цього блокування. Отже, ваш алгоритм значно постраждає. Скільки залежить від алгоритму та того, як часто викликається операція .. Ви не можете реально уникнути цього, не запровадивши гоночні умови, але ви можете покращити його, зменшивши кількість викликів до заблокованого коду.