კარგად გამოკვებადი ფილოსოფოსები ან კონკურენტუნარიანი .NET პროგრამირება

ვნახოთ, როგორ მუშაობს კონკურენტული და პარალელური პროგრამირება .Net-ში, მაგალითად ფილოსოფოსთა სასადილო პრობლემის გამოყენებით. გეგმა ასეთია, ძაფების/პროცესების სინქრონიზაციისგან, აქტორის მოდელამდე (შემდეგ ნაწილებში). სტატია შეიძლება სასარგებლო იყოს პირველი გაცნობისთვის ან თქვენი ცოდნის განახლებისთვის.

რატომ აკეთებ საერთოდ? ტრანზისტორები მიაღწევენ მინიმალურ ზომას, მურის კანონი ემყარება სინათლის სიჩქარის შეზღუდვას და ამიტომ შეინიშნება რიცხვის ზრდა, შეიძლება მეტი ტრანზისტორის დამზადება. ამავდროულად, მონაცემთა რაოდენობა იზრდება და მომხმარებლები სისტემებისგან მყისიერ პასუხს ელიან. ასეთ სიტუაციაში „ნორმალური“ პროგრამირება, როცა გვაქვს ერთი შემსრულებელი თემა, აღარ არის ეფექტური. თქვენ უნდა როგორმე გადაჭრათ ერთდროული ან ერთდროული შესრულების პრობლემა. უფრო მეტიც, ეს პრობლემა არსებობს სხვადასხვა დონეზე: ძაფების დონეზე, პროცესების დონეზე, ქსელში არსებული მანქანების დონეზე (განაწილებული სისტემები). .NET-ს აქვს მაღალი ხარისხის, დროში გამოცდილი ტექნოლოგიები ასეთი პრობლემების სწრაფად და ეფექტურად გადაჭრისთვის.

დავალება

Edsger Dijkstra-მ ეს პრობლემა თავის სტუდენტებს ჯერ კიდევ 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 ქმნის ან შლის ძაფებს ამ ამოცანების რაოდენობის მიხედვით. ერთი აუზი ყველა AppDomain-ისთვის. ეს აუზი უნდა იქნას გამოყენებული თითქმის ყოველთვის, რადგან. არ არის საჭირო თემების შექმნა, წაშლა, მათი რიგები და ა.შ. 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.

ფიგურაში, ძაფების ბლოკირება (ჩიხი). მწვანე - შესრულება, წითელი - სინქრონიზაცია, ნაცრისფერი - ძაფი სძინავს. რომბები მიუთითებს ამოცანების დაწყების დროს.

ფილოსოფოსთა შიმშილი

მართალია არ არის საჭირო განსაკუთრებით ბევრი საკვების ფიქრი, მაგრამ შიმშილი ნებისმიერს აიძულებს ფილოსოფიაზე უარი თქვას. შევეცადოთ ჩვენს პრობლემაში ძაფების შიმშილის სიტუაციის სიმულაცია. შიმშილი არის, როდესაც ძაფი ტრიალებს, მაგრამ მნიშვნელოვანი სამუშაოს გარეშე, სხვა სიტყვებით რომ ვთქვათ, ეს იგივე ჩიხია, მხოლოდ ახლა ძაფი არ სძინავს, არამედ აქტიურად ეძებს საჭმელს, მაგრამ საკვები არ არის. ხშირი დაბლოკვის თავიდან ასაცილებლად ჩანგალს უკან დავაბრუნებთ თუ მეორეს ვერ ავიღებთ.

// То же что и в 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 (რომელიც იქ გამოიყენება). ახლა მან იცის როგორ დათვალოს მომლოდინეები, დააძინოს ცოტა და სხვა. ზოგადად, ყველაფერს აკეთებს ოპტიმიზაციისთვის. მაგრამ უნდა გვახსოვდეს, რომ ეს არის იგივე აქტიური ციკლი, რომელიც ჭამს პროცესორის რესურსებს და ინარჩუნებს ნაკადს, რამაც შეიძლება გამოიწვიოს შიმშილი, თუ რომელიმე ფილოსოფოსი გახდება უფრო პრიორიტეტული ვიდრე სხვები, მაგრამ არ ექნება ოქროს ჩანგალი (Priority Inversion-ის პრობლემა) . ამიტომ, ჩვენ ვიყენებთ მას მხოლოდ საზიარო მეხსიერებაში ძალიან მოკლე ცვლილებებისთვის, ყოველგვარი მესამე მხარის ზარების, ჩადგმული საკეტების და სხვა სიურპრიზების გარეშე.

ხატვა ამისთვის SpinLock. ნაკადულები გამუდმებით „იბრძვიან“ ოქროს ჩანგალისთვის. არის წარუმატებლობები - ფიგურაში, არჩეული ტერიტორია. ბირთვები სრულად არ არის გამოყენებული: მხოლოდ დაახლოებით 2/3 ამ ოთხი ძაფით.

აქ კიდევ ერთი გამოსავალი იქნება მხოლოდ გამოყენება Interlocked.CompareExchange იგივე აქტიური მოლოდინით, როგორც ზემოთ მოცემულ კოდშია ნაჩვენები (მშიერი ფილოსოფოსებში), მაგრამ ამან, როგორც უკვე ითქვა, თეორიულად შეიძლება გამოიწვიოს დაბლოკვა.

on Interlocked უნდა აღინიშნოს, რომ არ არსებობს მხოლოდ CompareExchange, არამედ ატომური წაკითხვისა და ჩაწერის სხვა მეთოდებიც. და ცვლილების განმეორებით, იმ შემთხვევაში, თუ სხვა თემას აქვს დრო, რომ შეიტანოს ცვლილებები (წაიკითხეთ 1, წაიკითხეთ 2, ჩაწერეთ 2, ჩაწერეთ 1 ცუდია), ის შეიძლება გამოყენებულ იქნას ერთი მნიშვნელობის კომპლექსური ცვლილებებისთვის (Interlocked Anything pattern) .

ბირთვის რეჟიმის გადაწყვეტილებები

იმისათვის, რომ თავიდან ავიცილოთ რესურსების დახარჯვა მარყუჟში, ვნახოთ, როგორ შეგვიძლია დაბლოკოს თემა. სხვა სიტყვებით რომ ვთქვათ, გავაგრძელოთ ჩვენი მაგალითი, ვნახოთ, როგორ აძინებს მიმტანი ფილოსოფოსს და აღვიძებს მას მხოლოდ საჭიროების შემთხვევაში. პირველ რიგში, მოდით შევხედოთ როგორ გავაკეთოთ ეს ოპერაციული სისტემის ბირთვის რეჟიმში. იქ ყველა სტრუქტურა ხშირად უფრო ნელია ვიდრე მომხმარებლის სივრცეში. რამდენჯერმე ნელა, მაგალითად AutoResetEvent შესაძლოა 53-ჯერ ნელა SpinLock [რიხტერი]. მაგრამ მათი დახმარებით თქვენ შეგიძლიათ პროცესების სინქრონიზაცია მთელ სისტემაში, მართვადი თუ არა.

ძირითადი კონსტრუქცია აქ არის სემაფორი, რომელიც შემოთავაზებულია დიკსტრას მიერ ნახევარი საუკუნის წინ. სემაფორი, მარტივად რომ ვთქვათ, არის დადებითი მთელი რიცხვი, რომელსაც მართავს სისტემა და მასზე ორი ოპერაცია, ზრდა და შემცირება. თუ ის ვერ შემცირდა, ნულოვანი, მაშინ ზარის თემა იბლოკება. როდესაც რიცხვი იზრდება სხვა აქტიური ძაფით/პროცესით, მაშინ ძაფები გამოტოვებულია და სემაფორი კვლავ მცირდება გავლილი რიცხვით. შეიძლება წარმოვიდგინოთ მატარებლები ბოსტნეულში სემაფორთან. .NET გთავაზობთ რამდენიმე კონსტრუქციას მსგავსი ფუნქციონირებით: AutoResetEvent, ManualResetEvent, Mutex მე და მე Semaphore. ჩვენ გამოვიყენებთ AutoResetEvent, ეს არის ამ კონსტრუქციებიდან უმარტივესი: მხოლოდ ორი მნიშვნელობა 0 და 1 (false, true). მისი მეთოდი WaitOne() ბლოკავს გამოძახების თემას, თუ მნიშვნელობა იყო 0, ხოლო თუ 1, ამცირებს მას 0-მდე და გამოტოვებს მას. მეთოდი Set() აწევს 1-მდე და უშვებს ერთ მიმტანს, რომელიც ისევ 0-მდე დაბლა. მოქმედებს როგორც მეტროს ტურნიკი.

მოდით გავართულოთ გამოსავალი და გამოვიყენოთ საკეტი თითოეული ფილოსოფოსისთვის და არა ერთდროულად. იმათ. ახლა შეიძლება რამდენიმე ფილოსოფოსი იყოს ერთდროულად და არა ერთი. მაგრამ ჩვენ კვლავ ვბლოკავთ მაგიდაზე წვდომას, რათა სწორად, თავიდან ავიცილოთ რბოლა (რბოლის პირობები), ავიღოთ surebets.

// Для блокирования отдельного философа.
// Инициализируется: 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 ნიმუში საშუალებას გაძლევთ უფრო მოკლედ განახორციელოთ რაიმე რთული მდგომარეობის მოლოდინი. .NET-ში ის არასრულია, ჩემი აზრით, იმიტომ თეორიულად, უნდა იყოს რამდენიმე რიგი რამდენიმე ცვლადზე (როგორც Posix Threads-ში), და არა ერთ ლოკზე. მაშინ შეიძლება მათი დამზადება ყველა ფილოსოფოსისთვის. მაგრამ ამ ფორმითაც კი, ის საშუალებას გაძლევთ შეამციროთ კოდი.

ბევრი ფილოსოფოსი ან 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 მხარს უჭერს მრავალი სინქრონიზაციის კონსტრუქციას. თუმცა, ყოველთვის არ არის ნათელი, თუ როგორ გამოიყენოთ ისინი. იმედი მაქვს, რომ ეს სტატია სასარგებლო იყო. ჯერჯერობით ეს დასასრულია, მაგრამ კიდევ ბევრი საინტერესო რამ დარჩა, მაგალითად, thread-safe კოლექციები, TPL Dataflow, Reactive programming, Software Transaction model და ა.შ.

ინფორმაციის წყაროები

• ნაკადის ვიზუალიზაცია: კონკურენტულობის ვიზუალიზატორი
• MSDN: ძაფის, ასინქრონული პროგრამირების შაბლონები და მრავალი სხვა სხვა
• [Richter] - CLR C#-ით, ჯეფრი რიხტერი
• [ერიკ ლიპერტი] - ჩაკეტვის შესახებ
• კოდის კოდი
• სურათი - "ცეკვა ხმლებს შორის", გ.სემირადსკი

წყარო: www.habr.com