Добре охранени философи или състезателно програмиране в .NET

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

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

Задача

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

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

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

var cancelTokenSource = new CancellationTokenSource();
Action<int> create = (i) => RunPhilosopher(i, cancelTokenSource.Token);
for (int i = 0; i < philosophersAmount; i++) 
{
    int icopy = i;
    // Поместить задачу в очередь пула потоков. Метод RunDeadlock не запускаеться 
    // сразу, а ждет своего потока. Асинхронный запуск.
    philosophers[i] = Task.Run(() => create(icopy), cancelTokenSource.Token);
}

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

С други думи, System.Threading.Tasks.Task класът е същият Thread, но с всякакви удобства: възможност за стартиране на задача след блок от други задачи, връщането им от функции, удобното им прекъсване и много други. и т.н. Те са необходими за поддържане на конструкции async/await (асинхронен модел, базиран на задачи, синтактична захар за изчакване на 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.

На снимката блокиране на нишки (безизходица). Зеленото показва изпълнение, червеното показва синхронизация, а сивото показва, че нишката спи. Диамантите показват времето за стартиране на задачите.

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

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

// То же что и в 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
        {
            // Здесь может быть только один поток (mutual exclusion).
            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 (което се използва там). Сега той знае как да брои чакащите, да ги приспи малко и много повече. и т.н. Като цяло прави всичко възможно да оптимизира. Но трябва да помним, че това все още е същият активен цикъл, който изяжда ресурсите на процесора и поддържа нишка, което може да доведе до глад, ако един от философите стане с по-голям приоритет от останалите, но няма златна вилка (проблем с инверсията на приоритета ). Затова го използваме само за много много кратки промени в споделената памет, без никакви извиквания на трети страни, вложени заключвания или други изненади.

Рисуване за SpinLock. Потоците непрекъснато се „борят“ за златната вилка. Възникват повреди - маркираната област на фигурата. Ядрата не се използват напълно: само около 2/3 от тези четири нишки.

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

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

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

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

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

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

// Для блокирования отдельного философа.
// Инициализируется: 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 и т.н. Най-популярният дизайн тук е Monitor, защото в C# има добре познат lock синтаксис. Monitor това е същият семафор с максимална стойност 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 синтаксис има някои неприятни изненади. Препоръчва се за употреба Monitor директно [Рихтер] [Ерик Липерт]. Едно от тях е това lock винаги излиза Monitor, дори ако е имало изключение, и след това друга нишка може да промени състоянието на споделената памет. В такива случаи често е по-добре да влезете в задънена улица или по някакъв начин безопасно да прекратите програмата. Друга изненада е, че Мониторът използва часовникови блокове (SyncBlock), които присъстват във всички обекти. Следователно, ако е избран неподходящ обект, можете лесно да получите блокиране (например, ако заключите интерниран низ). Винаги използваме скрит предмет за това.

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

Много философи или async / await

Добре, сега можем ефективно да блокираме теми. Но какво ще стане, ако имаме много философи? 100? 10000 100000? Например, получихме 4 XNUMX заявки към уеб сървъра. Създаването на нишка за всяка заявка ще бъде скъпо, защото толкова много нишки няма да бъдат изпълнени паралелно. Само толкова логически ядра ще бъдат изпълнени (имам XNUMX). А всички останали просто ще отнемат ресурси. Едно решение на този проблем е моделът 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();
}

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

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

Заключение

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

източници

• Визуализация на потока: Визуализатор на едновременност
• MSDN: Threading, Модели на асинхронно програмиране и много други друг
• [Рихтер] — CLR чрез C#, Джефри Рихтер
• [Ерик Липерт] - Относно ключалката
• Изходен код
• Картина – „Танц сред мечовете”, Г. Семирадски

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