Ситите философи или конкурентно програмиране на .NET

Нека да видим как е устроено конкурентното и паралелното програмиране в .Net, използвайки проблема с философите, които обядват. Планът е такъв - от синхронизация на потоци/процеси до акторски модели (в следващите части). Статията може да бъде полезна както за първи запознанства, така и за освежаване на познанията.

Защо всъщност да умеем това? Транзисторите достигат минималния си размер, законът на Мур достига граница, зададена от скоростта на светлината, и затова растежът се наблюдава в количеството; може да се произвеждат повече транзистори. В същото време количеството данни нараства, а потребителите очакват незабавна реакция от системите. В такава ситуация „обикновеното“ програмиране, при което имаме един изпълняващ поток, вече не е ефективно. Нужно е да решим проблема с едновременното или конкурентно изпълнение. Освен това, този проблем съществува на различни нива: на ниво потоци, на ниво процеси, на ниво машини в мрежата (разпределени системи). В .NET има качествени, доказали се технологии за бързо и ефективно решаване на такива задачи.

Задача

Едсгер Дейкстра е поставил този проблем на своите студенти още през 1965 година. Установената формулировка е следната. Има определено (обикновено пет) количество философи и същото количество вилици. Те седят около кръгла маса, вилиците са между тях. Философите могат да ядат от чиниите си, които са пълни с безкрайна храна, да мислят или да чакат. За да яде философ, трябва да вземе две вилици (последният споделя вилица с първия). Вземането и поставянето на вилицата е две отделни действия. Всички философи мълчат. Задачата е да се намери такъв алгоритъм, че всички те да мислят и да бъдат сити, дори след 54 години.

Първо ще се опитаме да решим този проблем чрез използване на споделено място. Вилиците лежат на общата маса и философите просто ги вземат, когато са налични, и ги поставят обратно. Тук се появяват проблеми със синхронизацията: кога точно да се взимат вилиците? какво да се прави, ако вилицата не е налична? и др. Но първо нека да стартираме философите.

За стартиране на потоците използваме пул от потоци чрез Task.Run метод:

var cancelTokenSource = new CancellationTokenSource();
Action create = (i) => RunPhilosopher(i, cancelTokenSource.Token);
for (int i = 0; i  create(icopy), cancelTokenSource.Token);
}

Пул потокове е създаден за оптимизация на създаването и изтриването на потоци. Този пул има опашка с задачи и CLR създава или изтрива потоци в зависимост от броя на тези задачи. Един пул за всички AppDomain-ове. Този пул трябва да се използва почти винаги, тъй като не е необходимо да се занимавате с създаването, изтриването на потоци и техните опашки и т.н. Може и без пул, но тогава ще трябва да използвате директно Поток, това е разумно в случаи, когато трябва да промените приоритета на потока, когато имаме дълга операция, за Foreground поток и др.

С други думи, System.Threading.Tasks.Task класът — това е същото Поток, но с всякакви удобства: възможност да стартирате задача след блок от други задачи, да ги връщате от функции, удобно да ги прекъсвате и мн. др. Те са нужни за поддръжка на async/await конструкции (Task-based Asynchronous Pattern, синтактичен захар за очакване на IO операция). За това ще говорим по-късно.

CancelationTokenSource тук е необходим, за да може потокът сам да приключи по сигнал от извикващия поток.

Проблеми с синхронизация

Блокирани философи

Добре, умеем да създаваме потоци, да опитаме да обядваме:

// Кто какие вилки взял. К примеру: 1 1 3 3 - 1й и 3й взяли первые две пары.
private int[] forks = Enumerable.Repeat(0, philosophersAmount).ToArray();

// То же, что RunPhilosopher()
private void RunDeadlock(int i, CancellationToken token) 
{
    // Ждать вилку, взять её. Эквивалентно: 
    // while(true) 
    //     if forks[fork] == 0 
    //          forks[fork] = i+1
    //          break
    //     Thread.Sleep() или Yield() или SpinWait()
    void TakeFork(int fork) =>
        SpinWait.SpinUntil(() => 
            Interlocked.CompareExchange(ref forks[fork], i+1, 0) == 0);

    // Для простоты, но можно с Interlocked.Exchange:
    void PutFork(int fork) => forks[fork] = 0;

    while (true)
    {
        TakeFork(Left(i));
        TakeFork(Right(i));
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        PutFork(Left(i));
        PutFork(Right(i));
        Think(i);

        // Завершить работу по-хорошему.
        token.ThrowIfCancellationRequested();
    }
}

Тук първо опитваме да вземем лявата, а след това и дясната вилица и ако успеем, ядем и ги слагаме обратно. Вземането на една вилица е атомарно, т.е. два потока не могат да вземат една и съща вилица едновременно (неправилно: първият чете, че вилицата е свободна, вторият — също, първият взема, вторият взема). За това Interlocked.CompareExchange, който трябва да бъде реализиран с помощта на процесорна инструкция (TSL, XCHG), която блокира участок памет за атомарно последователно четене и запис. А SpinWait е еквивалентно на конструкцията while(true) само с малка «магия» — потокът заема процесора (Thread.SpinWait), но понякога предава управлението на друг поток (Thread.Yeild) или заспива (Thread.Sleep).

Но това решение не работи, тъй като потоковете скоро (при мен в рамките на секунда) се блокират: всички философи вземат своята лява вилица, а десната — не. Массивът forks тогава има стойности: 1 2 3 4 5.

На схемата, блокирането на потоковете (deadlock). В зелено — изпълнение, в червено — синхронизация, в сиво — поток спи. Ромбите обозначават времето за стартиране на Task-ове.

Глад на философите

Въпреки че не е необходимо да мислиш особено много, за да се нахраниш, гладът може да накара всеки да зареже философията. Нека опитаме да симулираме ситуация на глад на нишки в нашата задача. Гладът е, когато нишката работи, но без съществена работа, с други думи, това е същият дедлок, просто сега нишката не спи, а активно търси как да се нахрани, но храна няма. За да избегнем често блокиране, ще оставим вилицата назад, ако не сме успели да вземем друга.

// То же что и в RunDeadlock, но теперь кладем вилку назад и добавляем плохих философов.
private void RunStarvation(int i, CancellationToken token)
{
    while (true)
    {
        bool hasTwoForks = false;
        var waitTime = TimeSpan.FromMilliseconds(50);
        // Плохой философов может уже иметь вилку:
        bool hasLeft = forks[Left(i)] == i + 1;
        if (hasLeft || TakeFork(Left(i), i + 1, waitTime))
        {
            if (TakeFork(Right(i), i + 1, TimeSpan.Zero))
                hasTwoForks = true;
            else
                PutFork(Left(i)); // Иногда плохой философ отдает вилку назад.
        } 
        if (!hasTwoForks)
        {
            if (token.IsCancellationRequested) break;
            continue;
        }
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        bool goodPhilosopher = i % 2 == 0;
        // А плохой философ забывает положить свою вилку обратно:
        if (goodPhilosopher)
            PutFork(Left(i));
        // А если и правую не положит, то хорошие будут вообще без еды.
        PutFork(Right(i));

        Think(i);

        if (token.IsCancellationRequested)
            break;
    }
}

// Теперь можно ждать определенное время.
bool TakeFork(int fork, int philosopher, TimeSpan? waitTime = null)
{
    return SpinWait.SpinUntil(
        () => Interlocked.CompareExchange(ref forks[fork], philosopher, 0) == 0,
              waitTime ?? TimeSpan.FromMilliseconds(-1)
    );
}

В този код е важно, че двама от четирима философи забравят да сложат лявата си вилица. И в крайна сметка те ядат повече храна, а другите започват да гладуват, въпреки че нишките имат еднакъв приоритет. Тук те не гладуват напълно, тъй като лошите философи понякога оставят вилиците си назад. Изглежда, че добрите ядат около 5 пъти по-малко от лошите. Така че малка грешка в кода води до спад на производителността. Тук е важно да се отбележи, че съществува рядка ситуация, когато всички философи вземат лявата вилица, дясната е недостъпна, те оставят лявата, чакат, вземат отново лявата и т.н. Тази ситуация също е глад, по-скоро подобна на взаимна блокировка. Не успях да я повторя. По-долу е изображение на ситуация, когато двама лоши философи вземат и двете вилици, а двама добри гладуват.

Тук се вижда, че нишките понякога се събуждат и опитват да получат ресурс. Два от четири ядра нищо не правят (зеленият график отгоре).

Смърт на философа

И още една проблема, която може да прекъсне славния обяд на философите — ако един от тях внезапно умре с вилици в ръце (и да бъде погребан така). Тогава съседите ще останат без обяд. Пример за код за този случай можете да измислите сами, например се изключва NullReferenceException след като философът вземе вилиците. И, между другото, изключението няма да бъде обработено и кодът, който го извиква, просто няма да го улови (за това AppDomain.CurrentDomain.UnhandledException и др.). Следователно обработчиците на грешки са необходими в самите нишки и с коректно приключване.

Сервитьор

Добре, как да решим този проблем с взаимните блокировки, гладуването и смъртните случаи? Ще допускаме само един философ до вилиците, ще добавим взаимно изключване за това място. Как да направим този сервитьор и как философите ще му искат, въпросите са интересни.

Най-простият начин е философите просто постоянно да искат от сервитьора да им разреши достъп до вилиците. Тоест, сега философите няма да чакат вилицата да е наблизо, а ще чакат или ще искат от сервитьора. Първоначално ще използваме само потребителското пространство, в което не използваме прекъсвания за повикване на някакви процедури от ядрото.

Решения в потребителското пространство

Тук ще направим същото, което преди сме правили с една вилица и двама философи, ще се въртим в цикъл и ще чакаме. Но сега това ще бъдат всичките философи и ще има само една вилица, т.е. може да се каже, че ще яде само този философ, който е взел тази „златна вилица“ от сервитьора. За това ще използваме SpinLock.

private static SpinLock spinLock = new SpinLock();  // Нашият "сервитьор"
private void RunSpinLock(int i, CancellationToken token)
{
    while (true)
    {
        // Взаимна блокировка чрез busy waiting. Извикваме до try, за да
        // изхвърлим изключение в случай на грешка в самия SpinLock.
        bool hasLock = false;
        spinLock.Enter(ref hasLock);
        try
        {
            // Тук може да има само един поток (взаимно изключване).
            forks[Left(i)] = i + 1;  // Вземаме вилицата веднага, без чакане.
            forks[Right(i)] = i + 1;
            eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
            forks[Left(i)] = 0;
            forks[Right(i)] = 0;
        }
        finally
        {
            if(hasLock) spinLock.Exit();  // Избягваме проблема със смъртта на философа.
        }

        Think(i);

        if (token.IsCancellationRequested)
            break;
    }
}

SpinLock това е блокиратор, с грубо казано, същия while(true) { if (!lock) break; }, но с още по-голяма „магия“, отколкото в SpinWait (които там се използват). Сега той може да брои чакащи, леко да ги приспи и много други неща. Като цяло, прави всичко възможно за оптимизация. Но трябва да помним, че това е все пак активен цикъл, който поема ресурси на процесора и задържа поток, който може да доведе до глад (Priority Inversion problem), ако един от философите стане приоритетен пред другите, но не разполага със златната вилица. Затова го използваме само за много, много кратки промени в общата памет, без никакви външни извиквания, вложени блокировки и т.н. изненади.

Илюстрация за SpinLock. Потоците постоянно „се борят“ за златната вилица. Настъпват провали — в илюстрацията е обозначената област. Ядрото не се използва напълно: само около 2/3 от тези четири потока.

Друго решение тук би било да се използва само Interlocked.CompareExchange с активно изчакване, както е показано в кода по-горе (в гладните философи), но това, както вече беше споменато, теоретично може да доведе до блокировка.

За Interlocked трябва да се каже, че там не само CompareExchange, но и други методи за атомарно четене и писане. И чрез повторно изменение в случай, че друг поток успее да направи своите изменения (четене 1, четене 2, запис 2, запис 1 е лошо), той може да се използва за сложни промени на едно значение (Interlocked Anything шаблон).

Решения в режим на ядро

За да избегнем загубата на ресурси в цикъла, да видим как можем да блокираме потока. С други думи, продължавайки примера ни, да видим как сервитьорът ще приспи философа и ще го събуди само когато е необходимо. Първо, нека да разгледаме как да го направим през режима на ядро на операционната система. Всички структури там често се оказват по-бавни от тези в пространството на потребителя. По-бавни в няколко пъти, например AutoResetEvent може да бъде 53 пъти по-бавен SpinLock [Рихтер]. Но с тях можем да синхронизираме процеси в цялата система, независимо от управлението.

Основната конструкция тук е семафор, предложен от Дейкстра преди повече от половин век. Семафорът е, опростено казано, положително цяло число, управлявано от системата, и две операции върху него - увеличаване и намаляване. Ако не може да се намали до нула, тогава извикващият поток се блокира. Когато числото се увеличава от някой друг активен поток/процес, тогава потокът се пропуска, а семафорът отново се намалява с броя на преминалите. Може да се представи като влакове в тясно място с семафор. .NET предлага няколко конструкции с подобни функции: AutoResetEvent, ManualResetEvent, Mutex и сам Semaphore. Ще използваме AutoResetEvent, това е най-простата от тези конструкции: само две стойности 0 и 1 (false, true). Нейният метод WaitOne() блокира извикващия поток, ако стойността е била 0, а ако е 1, понижава я до 0 и го пропуска. Методът Set() увеличава до 1 и пропуска един чакащ, който отново я понижава до 0. Действа като натискащ капак в метрото.

Нека усложним решението и да използваме блокировка за всеки философ, а не за всички наведнъж. Т.е. сега могат да има няколко философи едновременно, а не само един. Но отново блокираме достъпа до масата, за да можем да вземем вилиците коректно, избягвайки гонки (race conditions).

// Для блокирования отдельного философа.
// Инициализируется: new AutoResetEvent(true) для каждого.
private AutoResetEvent[] philosopherEvents;

// Для доступа к вилкам / доступ к столу.
private AutoResetEvent tableEvent = new AutoResetEvent(true);

// Рождение философа.
public void Run(int i, CancellationToken token)
{
    while (true)
    {
        TakeForks(i); // Ждет вилки.
        // Обед. Может быть и дольше.
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        PutForks(i); // Отдать вилки и разблокировать соседей.
        Think(i);
        if (token.IsCancellationRequested) break;
    }
}

// Ожидать вилки в блокировке.
void TakeForks(int i)
{
    bool hasForks = false;
    while (!hasForks) // Попробовать еще раз (блокировка не здесь).
    {
        // Исключающий доступ к столу, без гонок за вилками.
        tableEvent.WaitOne();
        if (forks[Left(i)] == 0 && forks[Right(i)] == 0)
            forks[Left(i)] = forks[Right(i)] = i + 1;
        hasForks = forks[Left(i)] == i + 1 && forks[Right(i)] == i + 1;
        if (hasForks)
            // Теперь философ поест, выйдет из цикла. Если Set 
            // вызван дважды, то значение true.
            philosopherEvents[i].Set();
        // Разблокировать одного ожидающего. После него значение tableEvent в false.
        tableEvent.Set(); 
        // Если имеет true, не блокируется, а если false, то будет ждать Set от соседа.
        philosopherEvents[i].WaitOne();
    }
}

// Отдать вилки и разблокировать соседей.
void PutForks(int i)
{
    tableEvent.WaitOne(); // Без гонок за вилками.
    forks[Left(i)] = 0;
    // Пробудить левого, а потом и правого соседа, либо AutoResetEvent в true.
    philosopherEvents[LeftPhilosopher(i)].Set();
    forks[Right(i)] = 0;
    philosopherEvents[RightPhilosopher(i)].Set();
    tableEvent.Set();
}

За да разберем какво става, нека разгледаме случая, когато философът не успява да вземе вилиците, тогава действията му ще бъдат такива. Той чака достъп до масата. Получава го и опитва да вземе вилиците. Не успява. Той освобождава достъпа до масата (взаимно изключение). И преминава през своя „натискащ капак“ (AutoResetEvent) (в началото те са отворени). Попада отново в цикъл, тъй като няма вилици. Опитва да ги вземе и спира при своя „натискащ капак“. Някой по-успешен съсед отдясно или отляво, който е завършил да яде, освобождава нашия философ, „отваряйки неговия притискащ капак“. Нашият философ преминава през него (и той се затваря след него) за втори път. Опитва за трети път да вземе вилиците. Успешно. И преминава през своя натискащ капак, за да обядва.

Когато в такъв код има случайни грешки (те винаги съществуват), например, когато неправилно е указан съсед или е създаден един и същ обект AutoResetEvent за всички (Enumerable.Repeat), тогава философите ще чакат разработчиците, тъй като търсенето на грешки в такъв код е доста сложно начинание. Още една проблем с това решение е, че то не гарантира, че някой философ няма да започне да гладува.

Хибридни решения

Разгледахме два подхода за синхронизация, когато оставаме в режим на потребител и въртим цикъл, и когато блокираме потока през ядрото. Първият метод е добър за кратки блокировки, а вторият - за дълготрайни. Често се налага първо кратко да изчакваме промяна на променлива в цикъла, а след това да блокираме потока, когато очакването е дълго. Този подход е реализиран в т.н. хибридни конструкции. Тук имаме същите конструкции, каквито бяха за режима ядро, но сега с цикъл в режим на потребител: SemaphorSlim, ManualResetEventSlim и др. Най-популярната конструкция тук е Монитор, тъй като в C# има известния на всички lock синтаксис. Монитор това е същият семафор с максимална стойност 1 (мютекс), но с поддръжка на изчакване в цикъл, рекурсия, шаблон на променлива за условие (за него по-долу) и др. Нека да разгледаме решение с него.

// Спрячем объект для Монитора от всех, чтобы без дедлоков.
private readonly object _lock = new object();
// Время ожидания потока.
private DateTime?[] _waitTimes = new DateTime?[philosophersAmount];

public void Run(int i, CancellationToken token)
{
    while (true)
    {
        TakeForks(i);
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        PutForks(i);
        Think(i);
        if (token.IsCancellationRequested) break;
    }
}

// Наше сложное условие для Condition Variable паттерна.
bool CanIEat(int i)
{
    // Если есть вилки:
    if (forks[Left(i)] != 0 && forks[Right(i)] != 0)
        return false;
    var now = DateTime.Now;
    // Может, если соседи не более голодные, чем текущий.
    foreach(var p in new int[] {LeftPhilosopher(i), RightPhilosopher(i)})
        if (_waitTimes[p] != null && now - _waitTimes[p] > now - _waitTimes[i])
            return false;
    return true;
}

void TakeForks(int i)
{
    // Зайти в Монитор. То же самое: lock(_lock) {..}.
    // Вызываем вне try, чтобы возможное исключение выбрасывалось выше.
    bool lockTaken = false;
    Monitor.Enter(_lock, ref lockTaken);
    try
    {
        _waitTimes[i] = DateTime.Now;
        // Condition Variable паттерн. Освобождаем лок, если не выполненно 
        // сложное условие. И ждем пока кто-нибудь сделает Pulse / PulseAll.
        while (!CanIEat(i))
            Monitor.Wait(_lock); 
        forks[Left(i)] = i + 1;
        forks[Right(i)] = i + 1;
        _waitTimes[i] = null;
    }
    finally
    {
        if (lockTaken) Monitor.Exit(_lock);
    }
}

void PutForks(int i)
{
    // То же самое: lock (_lock) {..}.
    bool lockTaken = false;
    Monitor.Enter(_lock, ref lockTaken);
    try
    {
        forks[Left(i)] = 0;
        forks[Right(i)] = 0;
        // Освободить все потоки в очереди ПОСЛЕ вызова Monitor.Exit.
        Monitor.PulseAll(_lock); 
    }
    finally
    {
        if (lockTaken) Monitor.Exit(_lock);
    }
}

Тук отново блокираме цялата маса за достъп до вилиците, но сега отключваме всички потоци наведнъж, а не съседите, когато някой завърши да яде. Тоест, първо, някой яде и блокира съседите, а когато този някой завърши, но иска веднага отново да яде, той влиза в блокировка и буди съседите си, тъй като времето му за изчакване е по-малко.

Така избягваме задънени улици и гладуване на някой философ. Използваме цикъл за кратко изчакване и блокираме потока за дълго. Отключването на всички наведнъж работи по-бавно, отколкото ако отключваме само съседа, както в решението с AutoResetEvent, но разликата не трябва да е голяма, тъй като потокът трябва да остане в режим на потребител първоначално.

В lock синтаксисът носи неприятни изненади. Препоръчва се да се използва Монитор директно [Рихтер] [Ерик Липерт]. Една от тях е, че lock винаги излиза от Монитор, дори ако е имало изключение, и тогава друг поток може да промени състоянието на общата памет. В такива случаи по-често е по-добре да влезете в задънена улица или по някакъв безопасен начин да завършите програмата. Друга изненада е, че Monitor използва блокове за синхронизация (SyncBlock), които са налични във всички обекти. Следователно, ако се избере неподходящ обект, лесно може да се получи задънена улица (например, ако се направи лок върху интернирана строка). Винаги използваме скрит обект за това.

Паттерн Condition Variable позволява по-кратко да реализираме изчакване на сложни условия. В .NET той е непълен, според мен, тъй като идеята е да има няколко опашки за няколко променливи (както в Posix Threads), а не само на един лок. Тогава можем да създадем опашки за всички философи. Но дори и в този вид той позволява да съкратим кода.

Много философи или асинхронно / await

Добре, сега можем ефективно да блокираме нишки. Но какво, ако имаме много философи? 100? 10000? Например, получаваме 100000 заявки на уеб сървъра. Създаването на нишка за всяка заявка ще бъде разходно, тъй като толкова много нишки няма да могат да се изпълняват паралелно. Ще се изпълняват само толкова, колкото логически ядра (при мен са 4). А всички останали просто ще отнемат ресурси. Едно от решенията на този проблем е патърнът async / await. Идеята е, че функцията не задържа нишка, ако трябва да изчака нещо, за да продължи. А когато това нещо се случи, тя възобновява изпълнението си (но не задължително в същата нишка!). В нашия случай, ще изчакаме вилиците.

SemaphoreSlim има за цел WaitAsync() метод. Ето реализация с използване на този патърн.

// Запуск такой же, как раньше. Где-нибудь в программе:
Task.Run(() => Run(i, cancelTokenSource.Token));

// Запуск философа.
// Ключевое слово async -- компилятор транслирует этот метот в асинхронный.
public async Task Run(int i, CancellationToken token)
{
    while (true)
    {
        // await -- будем ожидать какого-то события.
        await TakeForks(i);
        // После await, продолжение возможно в другом потоке.
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        // Может быть несколько событий для ожидания.
        await PutForks(i);

        Think(i);

        if (token.IsCancellationRequested) break;
    }
}

async Task TakeForks(int i)
{
    bool hasForks = false;
    while (!hasForks)
    {
        // Взаимоисключающий доступ к столу:
        await _tableSemaphore.WaitAsync();
        if (forks[Left(i)] == 0 && forks[Right(i)] == 0)
        {
            forks[Left(i)] = i+1;
            forks[Right(i)] = i+1;
            hasForks = true;
        }
        _tableSemaphore.Release();
        // Будем ожидать, чтобы сосед положил вилки:
        if (!hasForks)
            await _philosopherSemaphores[i].WaitAsync();
    }
}

// Ждем доступа к столу и кладем вилки.
async Task PutForks(int i)
{
    await _tableSemaphore.WaitAsync();
    forks[Left(i)] = 0;
    // "Пробудить" соседей, если они "спали".
    _philosopherSemaphores[LeftPhilosopher(i)].Release();
    forks[Right(i)] = 0;
    _philosopherSemaphores[RightPhilosopher(i)].Release();
    _tableSemaphore.Release();
}

Методът с асинхронно / await се трансформира в хитър краен автомат, който веднага връща вътрешния си Task. Чрез него можем да изчакаме завършването на метода, да го отменим и всичко останало, което можем да правим с Task. Вътре в метода, крайният автомат контролира изпълнението. Същността е, че ако няма закъснение, изпълнението е синхронно, а ако има, нишката се освобождава. За по-добро разбиране на това, е по-добре да погледнем този краен автомат. Можем да създадем вериги от тези асинхронно / await методи.

Да тестваме. Работата на 100 философи на машина с 4 логически ядра, 8 секунди. Предходното решение с Monitor изпълняваше само 4-те първи нишки, а останалите не се изпълняваха изобщо. Всяка от тези 4 нишки е имала закъснение около 2мс. А решението с async / await изпълни всички 100, при средно изчакване от 6.8 секунди за всяка. Разбира се, в реалните системи закъснение от 6 секунди е неприемливо и е по-добре да не се обработват толкова заявки по този начин. Решението с Monitor се оказа напълно несъвместимо.

Заключение

Както личим от тези малки примери, .NET поддържа много конструкции за синхронизация. Не винаги, обаче, е очевидно как да ги използваме. Надявам се, че тази статия е била полезна. Сега завършваме, но има още много интересни теми, като колекции с безопасен достъп от потоци, TPL Dataflow, реактивно програмиране, модел на софтуерни транзакции и др.

Източници

• Визуализация на потоковете: Визуализатор на конкурентност
• MSDN: Многопоточност, Патерни за асинхронно програмиране и др.
• [Рихтер] — CLR via C#, Джефри Рихтер
• [Ерик Липперт] — За lock
• Изходен код
• Картина — «Танец сред мечове», Г. Семирадски

Източник: habr.com