Добро нахранети филозофи или конкурентно .NET програмирање

Ајде да видиме како функционира истовременото и паралелното програмирање во .Net, користејќи го како пример проблемот со јадење на Филозофи. Планот е овој, од синхронизација на нишки/процеси, до модел на актер (во следните делови). Статијата може да биде корисна за првото запознавање или за да го освежите вашето знаење.

Зошто воопшто да го направи тоа? Транзисторите ја достигнуваат својата минимална големина, Муровиот закон се потпира на ограничувањето на брзината на светлината и затоа се забележува зголемување на бројот, може да се направат повеќе транзистори. Во исто време, количината на податоци расте, а корисниците очекуваат итен одговор од системите. Во таква ситуација, „нормалното“ програмирање, кога имаме една нишка за извршување, веќе не е ефективно. Треба некако да го решите проблемот со истовремено или истовремено извршување. Покрај тоа, овој проблем постои на различни нивоа: на ниво на нишки, на ниво на процеси, на ниво на машини во мрежата (дистрибуирани системи). .NET има висококвалитетни, временски тестирани технологии за брзо и ефикасно решавање на ваквите проблеми.

Задача

Едсгер Дијкстра им го постави овој проблем на своите студенти уште во 1965 година. Воспоставената формулација е следна. Има одреден (обично пет) број на филозофи и исто толку вилушки. Тие седат на тркалезна маса, со вилушки меѓу нив. Филозофите можат да јадат од своите чинии со бескрајна храна, да размислуваат или да чекаат. За да јадете филозоф, треба да земете две виљушки (последната ја дели вилушката со првата). Подигнувањето и спуштањето на вилушката се две посебни дејства. Сите филозофи молчат. Задачата е да се најде таков алгоритам што сите би размислувале и би биле полни и по 54 години.

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

За да започнеме нишки, користиме базен со нишки 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 создава или отстранува нишки во зависност од бројот на овие задачи. Еден базен за сите AppDomains. Овој базен треба да се користи речиси секогаш, бидејќи. нема потреба да се замарате со креирање, бришење нишки, нивни редици итн. Можно е без базен, но потоа треба да го користите директно Thread, ова е корисно за случаи кога треба да го смените приоритетот на нишката, кога имаме долга операција, за нишка во преден план итн.

Со други зборови, System.Threading.Tasks.Task класата е иста Thread, но со секакви погодности: способност да извршите задача по блок други задачи, да ги вратите од функциите, удобно да ги прекинувате и многу повеќе. Тие се потребни за поддршка на асинхрони/чекачки конструкции (Асинхрона шема заснована на задачи, синтаксички шеќер за чекање операции на 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).

Но, ова решение не функционира, бидејќи тековите наскоро (за мене во секунда) се блокирани: сите филозофи ја земаат левата вилушка, но не и десната. Низата вилушки тогаш ги има вредностите: 1 2 3 4 5.

На сликата, блокирање на нишки (ќор-сокак). Зелена - извршување, црвена - синхронизација, сива - нишката спие. Ромбите го означуваат времето на започнување на Tasks.

Гладот ​​на филозофите

Иако не е неопходно да се размислува особено за храна, но гладта го тера секој да се откаже од филозофијата. Ајде да се обидеме да ја симулираме ситуацијата на гладување на нишки во нашиот проблем. Гладување е кога тече конец, но без значителна работа, со други зборови, ова е истиот ќорсокак, само што сега конецот не спие, туку активно бара нешто да јаде, но нема храна. За да избегнеме често блокирање, ќе ја вратиме вилушката ако не можеме да земеме друга.

// То же что и в 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 (неточно, точно). Нејзиниот метод 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 (mutex), но со поддршка за чекање во циклус, рекурзија, моделот Condition Variable (повеќе за тоа подолу), итн. Ајде да погледнеме решение со него.

// Спрячем объект для Монитора от всех, чтобы без дедлоков.
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 ви овозможува поконцизно да ги спроведете очекувањата за некоја сложена состојба. Во .НЕТ е нецелосно според мене затоа што во теорија, треба да има неколку редици на неколку променливи (како во Posix Threads), а не на еден lok. Тогаш може да се направат за сите филозофи. Но, дури и во оваа форма, тоа ви овозможува да го намалите кодот.

многу филозофи или async / await

Добро, сега можеме ефективно да ги блокираме нишките. Но, што ако имаме многу филозофи? 100? 10000? На пример, добивме 100000 барања до веб-серверот. Ќе биде преку глава да се создаде нишка за секое барање, бидејќи толку многу нишки нема да се одвиваат паралелно. Ќе работи само онолку колку што има логички јадра (имам 4). А сите останати само ќе одземат ресурси. Едно решение за овој проблем е шемата за асинхронизација / чекање. Неговата идеја е дека функцијата не ја држи нишката ако треба да чека нешто да продолжи. И кога прави нешто, продолжува да се извршува (но не мора да биде на истата нишка!). Во нашиот случај, ќе ја чекаме вилушката.

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 секунди. Претходното решение со монитор ги истрча само првите 4 нишки, а останатите воопшто не работеа. Секоја од овие 4 нишки беше во мирување околу 2 ms. И решението за асинхронизирање / чекање работи на сите 100, со просечно чекање од 6.8 секунди секое. Се разбира, во реалните системи, мирување 6 секунди е неприфатливо и подобро е да не се обработуваат толку многу барања како ова. Решението со Монитор се покажа дека воопшто не е скалабилно.

Заклучок

Како што можете да видите од овие мали примери, .NET поддржува многу конструкции за синхронизација. Сепак, не е секогаш очигледно како да ги користите. Се надевам дека овој напис беше корисен. Засега, ова е крајот, но останаа уште многу интересни работи, на пример, нишки збирки, TPL Dataflow, Reactive programming, Software Transaction model итн.

Извори

• Визуелизација на протокот: Визуелизатор на конкуренција
• MSDN: Нишка, Асинхрони шеми на програмирање и многу други. д-р
• [Рихтер] - CLR преку C#, Џефри Рихтер
• [Ерик Липерт] - За бравата
• Извор
• Слика - „Танц меѓу мечеви“, Г. Семирадски

Извор: www.habr.com