Well-Fed Philosophers သို့မဟုတ် Competitive .NET ပရိုဂရမ်းမင်း

Philosophers Dining Problem ကို နမူနာအဖြစ် အသုံးပြု၍ .Net တွင် တစ်ပြိုင်တည်း နှင့် အပြိုင် ပရိုဂရမ်းမင်း မည်သို့ အလုပ်လုပ်သည်ကို ကြည့်ကြပါစို့။ အစီအစဥ်သည် တွဲများ/လုပ်ငန်းစဉ်များကို ထပ်တူပြုခြင်းမှ သရုပ်ဆောင်မော်ဒယ်အထိ (အောက်ပါအပိုင်းများတွင်) ဖြစ်သည်။ ဆောင်းပါးသည် ပထမဆုံးအသိမိတ်ဆွေအတွက် သို့မဟုတ် သင့်အသိပညာကို ပြန်လည်ဆန်းသစ်ရန်အတွက် အသုံးဝင်ပေမည်။

ဘာကြောင့် အကုန်လုပ်တာလဲ။ ထရန်စစ္စတာများသည် ၎င်းတို့၏ အနိမ့်ဆုံးအရွယ်အစားသို့ ရောက်ရှိပြီး၊ Moore ၏ ဥပဒေသည် အလင်း၏ အမြန်နှုန်း ကန့်သတ်ချက်ပေါ်တွင် တည်ရှိနေပြီး ထို့ကြောင့် အရေအတွက် တိုးလာသည်ကို တွေ့ရှိရသဖြင့် ထရန်စစ္စတာများကို ပိုမိုလုပ်ဆောင်နိုင်သည်။ တစ်ချိန်တည်းမှာပင်၊ ဒေတာပမာဏတိုးပွားလာကာ သုံးစွဲသူများသည် စနစ်များမှ ချက်ချင်းတုံ့ပြန်မှုကို မျှော်လင့်ကြသည်။ ထိုသို့သောအခြေအနေမျိုးတွင်၊ ကျွန်ုပ်တို့တွင် လုပ်ဆောင်နေသော thread တစ်ခုရှိသောအခါ "သာမန်" ပရိုဂရမ်သည် ထိရောက်မှုမရှိတော့ပါ။ တစ်ပြိုင်နက်တည်း သို့မဟုတ် တစ်ပြိုင်နက်တည်း လုပ်ဆောင်ခြင်း၏ ပြဿနာကို သင် တစ်နည်းနည်းဖြင့် ဖြေရှင်းရန် လိုအပ်သည်။ ထို့အပြင်၊ ဤပြဿနာသည် မတူညီသောအဆင့်များတွင် ရှိနေသည်- thread အဆင့်၊ လုပ်ငန်းစဉ်အဆင့်တွင်၊ ကွန်ရက်အတွင်းရှိ စက်များအဆင့် (ဖြန့်ဝေထားသောစနစ်များ)။ .NET တွင် ထိုသို့သောပြဿနာများကို လျင်မြန်ထိရောက်စွာဖြေရှင်းရန်အတွက် အရည်အသွေးမြင့်ပြီး အချိန်နှင့်တပြေးညီစမ်းသပ်ထားသောနည်းပညာများရှိသည်။

လုပ်ငန်း

Edsger Dijkstra သည် ဤပြဿနာကို 1965 ခုနှစ်အစောပိုင်းတွင် သူ၏ကျောင်းသားများထံ တင်ပြခဲ့သည်။ ဖွဲ့စည်းမှုပုံစံမှာ အောက်ပါအတိုင်းဖြစ်သည်။ ဒဿနပညာရှင်အချို့ (များသောအားဖြင့် ငါးယောက်) နှင့် တူညီသော ခက်ရင်းခွဲအရေအတွက် ရှိသည်။ စားပွဲဝိုင်းမှာ ထိုင်ကြပြီး သူတို့ကြားက ခက်ရင်းခွတွေ။ ဒဿနပညာရှင်များသည် ၎င်းတို့၏ အဆုံးမရှိသော ပန်းကန်ပြားများမှ စားနိုင်သည်၊ တွေးတောနိုင်သည် သို့မဟုတ် စောင့်ဆိုင်းနိုင်သည်။ ဒဿနပညာရှင်တစ်ဦးကိုစားရန် သင်သည် ခက်ရင်းနှစ်ချောင်းယူရန် လိုအပ်သည် (နောက်ဆုံးတစ်ခုသည် ပထမတစ်ခုနှင့် ခက်ရင်းကိုမျှဝေသည်)။ လမ်းဆုံလမ်းခွကို ကောက်ခြင်းနှင့် ချခြင်းသည် သီးခြားလုပ်ဆောင်မှု နှစ်ခုဖြစ်သည်။ ဒဿနပညာရှင်အားလုံး တိတ်ဆိတ်နေကြသည်။ တာဝန်မှာ ၅၄ နှစ်ကြာပြီးနောက်တွင်ပင် ၎င်းတို့အားလုံး တွေးထင်ကာ ပြည့်နေမည့် အယ်လဂိုရီသမ်တစ်ခုကို ရှာဖွေရန်ဖြစ်သည်။

ဦးစွာ၊ မျှဝေထားသောနေရာကို အသုံးပြုခြင်းဖြင့် ဤပြဿနာကို ဖြေရှင်းကြပါစို့။ ခက်ရင်းခွများသည် အများသူငှာ စားပွဲပေါ်တွင် လှဲနေပြီး ဒဿနပညာရှင်များသည် ၎င်းတို့ရှိသည့်အခါတွင် ၎င်းတို့ကို ရိုးရိုးရှင်းရှင်းယူ၍ ပြန်ထားကြသည်။ ဤနေရာတွင် surebets ကို အတိအကျယူရန် မည်သည့်အချိန်တွင် ထပ်တူပြုခြင်းတွင် ပြဿနာများရှိပါသည်။ လမ်းဆုံလမ်းခွမရှိရင် ဘယ်လိုလုပ်မလဲ။ စသည်တို့ကို ဦးစွာပထမ၊ ဒဿနပညာရှင်များကို စတင်ကြပါစို့။

စာတွဲများစတင်ရန် ကျွန်ုပ်တို့သည် thread pool ကိုအသုံးပြုသည်။ 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);
}

thread pool သည် thread ဖန်တီးခြင်းနှင့် ဖျက်ခြင်းတို့ကို အကောင်းဆုံးဖြစ်အောင် ဒီဇိုင်းထုတ်ထားသည်။ ဤအစုအဝေးတွင် လုပ်ဆောင်စရာများပါသည့် တန်းစီတစ်ခုရှိပြီး CLR သည် အဆိုပါလုပ်ဆောင်စရာအရေအတွက်ပေါ်မူတည်၍ စာတွဲများကို ဖန်တီး သို့မဟုတ် ဖယ်ရှားသည်။ AppDomains အားလုံးအတွက် ရေကူးကန်တစ်ခု။ ဘာကြောင့်လဲဆိုတော့ ဒီရေကန်ကို အမြဲတမ်းလိုလို သုံးသင့်ပါတယ်။ စာတွဲများ ဖန်တီးခြင်း၊ ဖျက်ခြင်း၊ ၎င်းတို့၏ တန်းစီခြင်း စသည်တို့ကို နှောက်ယှက်ရန် မလိုအပ်ပါ။ ရေကူးကန်မပါဘဲ ဖြစ်နိုင်သော်လည်း ၎င်းကို တိုက်ရိုက်အသုံးပြုရန် လိုအပ်ပါသည်။ Thread၊ ကျွန်ုပ်တို့တွင် ကြာရှည်စွာလုပ်ဆောင်မှုတစ်ခု၊ Foreground thread စသည်တို့အတွက် သင်က thread တစ်ခု၏ ဦးစားပေးကို ပြောင်းလဲရန် လိုအပ်သောအခါတွင် ၎င်းသည် အသုံးဝင်သည်။

တစ်နည်းပြောရရင်တော့, System.Threading.Tasks.Task အတန်းကတော့ အတူတူပါပဲ။ Threadအဆင်ပြေမှုအမျိုးမျိုးဖြင့်- အခြားလုပ်ဆောင်စရာများကို ပိတ်ဆို့ပြီးနောက် လုပ်ဆောင်နိုင်မှု၊ လုပ်ဆောင်ချက်များမှ ၎င်းတို့ကို ပြန်ပေးခြင်း၊ ၎င်းတို့ကို အဆင်ပြေစွာ နှောင့်ယှက်ခြင်းနှင့် အခြားအရာများ လုပ်ဆောင်နိုင်ခြင်း။ စသည်တို့ကို async/ait builds များကို ပံ့ပိုးရန် ၎င်းတို့သည် လိုအပ်သည် (Task-based Asynchronous Pattern၊ IO လုပ်ဆောင်မှုများကို စောင့်ဆိုင်းရန်အတွက် syntactic သကြား)။ ဒီအကြောင်းကို နောက်မှပြောပါမယ်။

CancelationTokenSource calling thread ၏ signal တွင် thread သည် သူ့ဘာသာသူ အဆုံးသတ်နိုင်စေရန် ဤနေရာတွင် လိုအပ်ပါသည်။

ထပ်တူကျသော ပြဿနာများ

ပိတ်ဆို့ခံထားရသော ဒဿနိကပညာရှင်

ကောင်းပြီ၊ စာကြောင်းများဖန်တီးနည်းကို ကျွန်ုပ်တို့သိသည်၊ နေ့လယ်စာစားကြပါစို့။

// Кто какие вилки взял. К примеру: 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 သည် processor ကိုယူသည် (Thread.SpinWait) သို့သော် တစ်ခါတစ်ရံတွင် ထိန်းချုပ်မှုကို အခြားအကြောင်းအရာသို့ လွှဲပြောင်းပေးသည် (Thread.Yeild) သို့မဟုတ် အိပ်ပျော်သွားသည် (Thread.Sleep).

ဒါပေမယ့် ဒီဖြေရှင်းချက်က အလုပ်မဖြစ်တာကြောင့်ပါ။ မကြာမီ (ငါ့အတွက် တစ်စက္ကန့်အတွင်း) စီးဆင်းမှုကို ပိတ်ဆို့သွားသည်- ဒဿနပညာရှင်အားလုံးသည် ၎င်းတို့၏ ဘယ်ဘက်ခွဆုံကို ယူသော်လည်း ညာဘက်ကို မယူပါ။ ထို့နောက် forks array တွင် တန်ဖိုးများ ရှိသည်- 1 2 3 4 5 ။

ပုံတွင်၊ thread များကိုပိတ်ဆို့ခြင်း (deadlock)။ အစိမ်းရောင် - ကွပ်မျက်ခြင်း၊ အနီရောင် - ထပ်တူပြုခြင်း၊ မီးခိုးရောင် - ချည်မျှင်သည်အိပ်ပျော်နေသည်။ အရုပ်များသည် Tasks ၏စတင်ချိန်ကိုညွှန်ပြသည်။

The Hunger of the Philosophers

အထူးသဖြင့် အစားအသောက် အများကြီး တွေးဖို့ မလိုအပ်ပေမယ့် ငတ်မွတ်မှုက ဘယ်သူမဆို အတွေးအခေါ်ကို အရှုံးပေးစေတယ်။ ကျွန်ုပ်တို့၏ပြဿနာရှိ ချည်မျှင်များ၏ ငတ်မွတ်ခေါင်းပါးမှုအခြေအနေကို ပုံဖော်ကြည့်ရအောင်။ ငတ်မွတ်ခြင်းသည် ချည်မျှင်တစ်ခုလည်ပတ်နေသော်လည်း သိသာထင်ရှားသောအလုပ်မရှိဘဲ၊ တစ်နည်းအားဖြင့်ပြောရလျှင် ဤအရာသည် တူညီသောမသေတ္တာဖြစ်သည်၊ ယခုသာချည်မျှင်သည် အိပ်မပျော်သော်လည်း စားစရာတစ်ခုခုကို တက်ကြွစွာရှာဖွေနေသော်လည်း အစာမရှိပေ။ မကြာခဏ ပိတ်ဆို့ခြင်းကို ရှောင်ရှားရန် အခြားတစ်ခုကို မယူနိုင်ခဲ့ပါက ခက်ရင်းကို ပြန်ထားပါမည်။

// То же что и в 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)
    );
}

ဤကုဒ်၏ အရေးကြီးသောအချက်မှာ ဒဿနပညာရှင် လေးဦးတွင် နှစ်ဦးသည် ၎င်းတို့၏ ဘယ်ဘက်ခွဆုံကို ချရန် မေ့လျော့နေခြင်းဖြစ်သည်။ အမျှင်များသည် တူညီသောဦးစားပေးဖြစ်သော်လည်း အခြားသူများ အစာငတ်လာချိန်တွင် ၎င်းတို့သည် အစာပိုစားကြသည်ကို တွေ့ရှိရသည်။ ဒီမှာ သူတို့ လုံးဝ ငတ်နေတာ မဟုတ်ဘူး။ မကောင်းတဲ့ ဒဿနပညာရှင်တွေဟာ တစ်ခါတစ်ရံမှာ သူတို့ရဲ့ ခွဆုံတွေကို ကျောခိုင်းထားကြပါတယ်။ လူကောင်းတွေ စားတာ မကောင်းတာထက် ၅ ဆလောက် ပိုနည်းတယ်။ ထို့ကြောင့် ကုဒ်တွင် သေးငယ်သော အမှားသည် စွမ်းဆောင်ရည် ကျဆင်းသွားစေသည်။ ဒဿနပညာရှင်အားလုံး ဘယ်ဘက်လမ်းဆုံကို ကိုင်လိုက်၊ ညာဘက်မရှိ၊ ဘယ်ဘက်ထား၊ စောင့်၊ ဘယ်ဘက်ပြန်ယူ၊ စသည်ဖြင့် ကြုံတောင့်ကြုံခဲ အခြေအနေတစ်ခု ဖြစ်နိုင်သည်ကိုလည်း ဤနေရာတွင် သတိပြုသင့်သည်။ ဤအခြေအနေသည် ငတ်မွတ်ခေါင်းပါးမှုတစ်ခုဖြစ်ပြီး မသေမချာဖြစ်နေသည့် အခြေအနေတစ်ခုလည်းဖြစ်သည်။ ထပ်ပြောဖို့ ပျက်ကွက်ခဲ့တယ်။ အောက်ဖော်ပြပါပုံသည် မကောင်းတဲ့ဒဿနပညာရှင်နှစ်ယောက် လမ်းခွဲလိုက်ကြပြီး ကောင်းသူနှစ်ယောက် ငတ်နေတဲ့ အခြေအနေအတွက် ပုံဖြစ်ပါတယ်။

ဤနေရာတွင် စာတွဲများသည် တစ်ခါတစ်ရံ နိုးထလာပြီး အရင်းအမြစ်ကို ရယူရန် ကြိုးစားသည်ကို ဤနေရာတွင် သင်တွေ့မြင်နိုင်ပါသည်။ core လေးခုထဲက နှစ်ခုက ဘာမှမလုပ်ပါဘူး (အထက်က ဂရပ်အစိမ်း)။

ဒဿနိကပညာရှင်တစ်ဦးသေဆုံး

ကောင်းပြီ၊ ဒဿနပညာရှင်တို့၏ ကျက်သရေရှိသော ညစာစားပွဲကို နှောက်ယှက်နိုင်သည့် နောက်ပြဿနာတစ်ခုမှာ ၎င်းတို့အနက်မှ တစ်ဦးသည် ရုတ်တရက် ခက်ရင်းခွဖြင့် သေဆုံးသွားပါက (ထိုကဲ့သို့ မြှုပ်နှံမည်)။ ထို့နောက် အိမ်နီးနားချင်းများကို နေ့လယ်စာ မစားဘဲ ထားခဲ့သည်။ ဤကိစ္စအတွက် သင်ကိုယ်တိုင် ဥပမာကုဒ်တစ်ခု တက်လာနိုင်သည်၊ ဥပမာ၊ ၎င်းကို ထုတ်ပစ်လိုက်ပါ။ NullReferenceException ဒဿနပညာရှင်သည် ခက်ရင်းများကို ယူပြီးနောက်၊ ပြီးတော့၊ စကားမစပ်၊ ခြွင်းချက်က ကိုင်တွယ်မှာ မဟုတ်ဘူး၊ ခေါ်ဆိုမှုကုဒ်က ဖမ်းရုံနဲ့ မရပါဘူး (ဒါအတွက် AppDomain.CurrentDomain.UnhandledException စသည်ဖြင့်)။ ထို့ကြောင့်၊ threads များတွင် error handlers များကိုယ်တိုင်နှင့် သပ်ရပ်စွာ ရပ်စဲခြင်းဖြင့် လိုအပ်ပါသည်။

စာပှဲထိုး

အိုကေ၊ ဒီပိတ်လှောင်မှု၊ ငတ်မွတ်မှုနဲ့ သေခြင်းပြဿနာကို ဘယ်လိုဖြေရှင်းမလဲ။ ကျွန်ုပ်တို့သည် ဒဿနပညာရှင်တစ်ဦးတည်းသာ လမ်းဆုံလမ်းခွသို့ရောက်ရှိရန် ခွင့်ပြုမည်ဖြစ်ပြီး ဤနေရာအတွက် အပြန်အလှန်ချန်လှပ်ထားသော ချည်မျှင်များကို ထည့်ပါ။ ဘယ်လို လုပ်ရမလဲ? ဒဿနပညာရှင်တစ်ယောက်ယောက်ကို လမ်းခွဲဖို့ စားပွဲထိုးတစ်ယောက်က ခွင့်မပြုတဲ့ ဒဿနပညာရှင်ဘေးမှာ ရပ်နေတယ်ဆိုပါစို့။ ဒီစားပွဲထိုးကို ငါတို့ဘယ်လိုလုပ်ရမလဲ၊ ဒဿနပညာရှင်တွေက သူ့ကို ဘယ်လိုမေးကြမလဲဆိုတဲ့ မေးခွန်းတွေက စိတ်ဝင်စားစရာပါ။

အရိုးရှင်းဆုံးနည်းလမ်းမှာ ဒဿနပညာရှင်များသည် လမ်းဆုံလမ်းခွများဆီသို့ စားပွဲထိုးအား အဆက်မပြတ်တောင်းဆိုနေချိန်ဖြစ်သည်။ အဲဒါတွေ။ ယခုအခါ ဒဿနပညာရှင်များသည် အနီးနားရှိ လမ်းခွဲတစ်ခုကို မစောင့်ဘဲ စားပွဲထိုးကို စောင့်ဆိုင်းနေမည် ဖြစ်သည်။ အစပိုင်းတွင်၊ ကျွန်ုပ်တို့သည် ၎င်းအတွက် User Space ကိုသာအသုံးပြုသည်၊ ၎င်းတွင် kernel မှ မည်သည့်လုပ်ထုံးလုပ်နည်းကိုမဆို ခေါ်ရန် ကြားဖြတ်အသုံးမပြုပါ (အောက်ပါ ၎င်းတို့အကြောင်း)။

အသုံးပြုသူနေရာရှိ ဖြေရှင်းချက်များ

ဤတွင် ကျွန်ုပ်တို့သည် လမ်းဆုံလမ်းခွတစ်ခုနှင့် ဒဿနိကပညာရှင် နှစ်ဦးတို့ ကျင့်သုံးခဲ့သည့်အတိုင်း ကျွန်ုပ်တို့ လုပ်ဆောင်မည်ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် သံသရာတစ်ခုတွင် လှည့်ပတ်ပြီး စောင့်မျှော်နေပါမည်။ ယခုမူ ၎င်းသည် ဒဿနပညာရှင်အားလုံး ဖြစ်လိမ့်မည်ဖြစ်ပြီး၊ ၎င်းကဲ့သို့ပင် လမ်းဆုံလမ်းခွတစ်ခုသာ ဖြစ်သည်။ စားပွဲထိုးထံမှ ဤ “ရွှေခက်ရင်း” ကိုယူသော ဒဿနပညာရှင်သာလျှင် စားလိမ့်မည်ဟု ဆိုနိုင်သည်။ ၎င်းအတွက်ကျွန်ုပ်တို့သည် 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 ဒါက blocker တစ်ခုပါ၊ အကြမ်းဖျင်းပြောရရင် အတူတူပါပဲ။ while(true) { if (!lock) break; }ဒါပေမယ့် ထက်တောင် ပိုတဲ့ "ပဉ္စလက်" နဲ့ SpinWait (အဲဒီမှာသုံးတယ်။ ယခု သူစောင့်ဆိုင်းနေသူများကို ရေတွက်နည်း၊ သူတို့ကို နည်းနည်းအိပ်ခိုင်းပြီး နောက်ထပ်အရာများကို သူသိသည်။ စသည်တို့ကို ယေဘုယျအားဖြင့် optimize ဖြစ်နိုင်သမျှ အကုန်လုပ်ပေးသည်။ သို့သော် ဒဿနိကပညာရှင်တစ်ဦးသည် အခြားသူများထက် ပို၍ဦးစားပေးဖြစ်လာသော်လည်း ရွှေလမ်းဆုံ (Priority Inversion ပြဿနာ) မပါရှိပါက ၎င်းသည် ပရိုဆက်ဆာအရင်းအမြစ်များကို စားသုံးပြီး စီးဆင်းမှုကို ထိန်းသိမ်းပေးသည့် တက်ကြွသောလည်ပတ်မှုသံသရာနှင့် အတူတူပင်ဖြစ်ကြောင်း ကျွန်ုပ်တို့ သတိရရမည်ဖြစ်သည်။ . ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ပြင်ပမှခေါ်ဆိုမှုများ၊ nested locks နှင့် အခြားအံ့သြစရာများမပါဘဲ မျှသုံးမှတ်ဉာဏ်တွင် အလွန်တိုတောင်းသောပြောင်းလဲမှုများအတွက်သာ အသုံးပြုပါသည်။

ပုံဆွဲဘို့ SpinLock. စမ်းချောင်းများသည် ရွှေလမ်းဆုံအတွက် အဆက်မပြတ် “တိုက်ပွဲ” ဖြစ်နေသည်။ ပျက်ကွက်မှုများရှိသည် - ပုံတွင်၊ ရွေးချယ်ထားသောဧရိယာ။ cores များကို အပြည့်အဝ အသုံးမပြုပါ- ဤ thread လေးခုမှ 2/3 ခန့်သာရှိသည်။

ဤနေရာတွင် နောက်ထပ်ဖြေရှင်းချက်မှာ အသုံးပြုရန်သာဖြစ်သည်။ Interlocked.CompareExchange အထက်ကုဒ်တွင်ပြထားသည့်အတိုင်း တူညီသောတက်ကြွစွာစောင့်ဆိုင်းခြင်းဖြင့် (ငတ်မွတ်ခေါင်းပါးသောအတွေးအခေါ်ပညာရှင်များတွင်)၊ သို့သော်၊ ဤအရာသည် သီအိုရီအရပိတ်ဆို့ခြင်းဆီသို့ ဦးတည်သွားနိုင်သည်။

အပေါ် Interlocked သပ်သပ်မရှိသည်ကို သတိပြုသင့်သည်။ CompareExchangeဒါပေမယ့် atomic read AND write အတွက် တခြားနည်းလမ်းတွေလည်း ပါပါတယ်။ အပြောင်းအလဲကို ထပ်ခါတလဲလဲလုပ်ခြင်းဖြင့်၊ အခြားစာတွဲတစ်ခုသည် ၎င်း၏ပြောင်းလဲမှုများကိုပြုလုပ်ရန်အချိန်ရှိလျှင် (၁ ကိုဖတ်ပါ၊ ၂၊ ရေးပါ၊ ၂၊ စာ ၁ သည် မကောင်းပါ)၊ ၎င်းကို တန်ဖိုးတစ်ခုတည်းသို့ ရှုပ်ထွေးသောပြောင်းလဲမှုများအတွက် သုံးနိုင်သည် (Interlocked Anything pattern) .

Kernel မုဒ်ဖြေရှင်းချက်

စက်ဝိုင်းတစ်ခုတွင် အရင်းအမြစ်များကို ဖြုန်းတီးခြင်းမှ ရှောင်ကြဉ်ရန်၊ ကြိုးတစ်ခုကို မည်သို့ပိတ်ဆို့နိုင်သည်ကို ကြည့်ကြပါစို့။ တစ်နည်းဆိုရသော် ကျွန်ုပ်တို့၏နမူနာကိုဆက်၍ စားပွဲထိုးသည် ဒဿနပညာရှင်အား အိပ်ပျော်စေရန်နှင့် လိုအပ်သည့်အခါမှသာ နှိုးပေးပုံကို ကြည့်ကြပါစို့။ ပထမဦးစွာ၊ လည်ပတ်မှုစနစ်၏ kernel မုဒ်မှတဆင့် ၎င်းကို မည်သို့လုပ်ဆောင်ရမည်ကို ကြည့်ကြပါစို့။ တည်ဆောက်မှုအားလုံးသည် အသုံးပြုသူနေရာရှိ များထက် နှေးကွေးလေ့ရှိသည်။ ဥပမာအားဖြင့် အကြိမ်ကြိမ်နှေးကွေးသည်။ AutoResetEvent 53 ဆ ပိုနှေးနိုင်ပါတယ်။ SpinLock [ Richter ] သို့သော် ၎င်းတို့၏အကူအညီဖြင့်၊ သင်သည် စနစ်တစ်လျှောက်လုံး လုပ်ငန်းစဉ်များကို တစ်ပြိုင်တည်းလုပ်ဆောင်နိုင်သည်၊ စီမံခန့်ခွဲသည်ဖြစ်စေ မပြုလုပ်ပါ။

ဤနေရာတွင် အခြေခံတည်ဆောက်ပုံသည် လွန်ခဲ့သော ရာစုနှစ်တစ်ဝက်ကျော်က Dijkstra မှ တင်ပြခဲ့သော semaphore ဖြစ်သည်။ Semaphore ဆိုသည်မှာ စနစ်က စီမံခန့်ခွဲသော အပြုသဘောဆောင်သော ကိန်းပြည့်ဖြစ်ပြီး ၎င်းတွင် လုပ်ဆောင်မှု နှစ်ခု၊ အတိုးနှင့် အလျှော့အတင်းရှိသည်။ အကယ်၍ ၎င်းသည် ကျဆင်းရန် ပျက်ကွက်ပါက သုည၊ ထို့နောက် ဖုန်းခေါ်ဆိုမှုလိုင်းကို ပိတ်ထားသည်။ နံပါတ်ကို အခြားအသက်ဝင်နေသော thread/process အချို့က တိုးလာသောအခါ၊ thread များကို ကျော်သွားကာ semaphore ကို ကျော်လွန်သွားသော အရေအတွက်အားဖြင့် တစ်ဖန် လျော့ကျသွားပါသည်။ semaphore ဖြင့် တစ်ဆို့နေသော ရထားများကို စိတ်ကူးကြည့်နိုင်သည်။ .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) သို့ဖြစ်လျှင် ဒဿနပညာရှင်များသည် တီထွင်သူအား စောင့်ဆိုင်းနေလိမ့်မည်ဖြစ်သောကြောင့်၊ ထိုသို့သောကုဒ်များတွင် အမှားအယွင်းများကို ရှာဖွေခြင်းသည် အလွန်ခက်ခဲသော အလုပ်ဖြစ်သည်။ ဤဖြေရှင်းချက်၏နောက်ထပ်ပြဿနာမှာ တွေးခေါ်ပညာရှင်အချို့ ဗိုက်ဆာမည်မဟုတ်ကြောင်း အာမမခံနိုင်ပါ။

ပေါင်းစပ်ဖြေရှင်းချက်

ကျွန်ုပ်တို့သည် အသုံးပြုသူမုဒ်နှင့် စက်ဝိုင်းတွင်ရှိနေသောအခါ၊ နှင့် kernel မှတဆင့် thread ကိုပိတ်ဆို့သောအခါတွင် အချိန်ကိုက်ရန် ချဉ်းကပ်မှုနှစ်ခုကို ကျွန်ုပ်တို့ကြည့်ရှုထားပါသည်။ ပထမနည်းလမ်းသည် တိုတောင်းသောသော့ခတ်ခြင်းအတွက် ကောင်းမွန်ပြီး ဒုတိယနည်းလမ်းမှာ ရှည်လျားသောသော့ခလောက်များဖြစ်သည်။ ကွင်းဆက်တစ်ခုတွင် ပြောင်းလဲနိုင်သော ကိန်းရှင်တစ်ခုကို အတိုချုံးစောင့်ဆိုင်းရန် ဦးစွာ လိုအပ်ပြီး စောင့်ဆိုင်းမှု ကြာလာသောအခါတွင် thread ကို ပိတ်ဆို့ရန် လိုအပ်သည်။ ဒီချဉ်းကပ်နည်းကို အကောင်အထည်ဖော်တာလို့ ခေါ်ပါတယ်။ ပေါင်းစပ်ဖွဲ့စည်းပုံများ။ ဤသည်မှာ kernel မုဒ်အတွက် တူညီသောတည်ဆောက်ပုံများဖြစ်သည်၊ သို့သော် ယခုအသုံးပြုသူမုဒ် loop တစ်ခုဖြင့် SemaphorSlim, ManualResetEventSlim etc. ဒီမှာ လူကြိုက်အများဆုံး ဒီဇိုင်းပါ။ Monitor, ဘာဖြစ်လို့လဲဆိုတော့ C# မှာ လူသိများပါတယ်။ lock အထားအသို Monitor ၎င်းသည် အများဆုံးတန်ဖိုး 1 (mutex) နှင့် တူညီသော်လည်း loop တစ်ခုတွင် စောင့်ဆိုင်းရန်၊ recursion၊ 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 syntax တွင် ဆိုးရွားသော အံ့သြဖွယ်ရာများရှိသည်။ အသုံးပြုရန် အကြံပြုအပ်ပါသည်။ Monitor တိုက်ရိုက် [Richter] [Eric Lippert]။ တယောက်က အဲဒါ lock အမြဲတမ်းထွက် Monitorခြွင်းချက်တစ်ခုရှိလျှင်ပင်၊ အခြားအကြောင်းအရာသည် မျှဝေထားသော မှတ်ဉာဏ်အခြေအနေကို ပြောင်းလဲနိုင်သည်။ ထိုသို့သောအခြေအနေမျိုးတွင်၊ မကြာခဏပိတ်သွားခြင်း သို့မဟုတ် ပရိုဂရမ်ကို လုံခြုံစွာပိတ်ပစ်ခြင်းသည် မကြာခဏဆိုသလို ပိုကောင်းသည်။ နောက်ထပ်အံ့အားသင့်စရာမှာ Monitor သည် synchronization လုပ်ကွက်များကိုအသုံးပြုသည် (SyncBlock၎) အရာဝတ္ထုအားလုံး၌ တည်ရှိခြင်း။ ထို့ကြောင့်၊ မသင့်လျော်သော အရာတစ်ခုကို ရွေးချယ်ပါက၊ သင်သည် အလွယ်တကူ မပိတ်မိနိုင်သည် (ဥပမာ၊ သင်ထည့်သွင်းထားသော စာကြောင်းတစ်ခုတွင် လော့ခ်ချပါက)။ ဤအတွက် ကျွန်ုပ်တို့သည် အမြဲတမ်းဝှက်ထားသော အရာဝတ္ထုကို အသုံးပြုသည်။

Condition Variable ပုံစံသည် သင့်အား ရှုပ်ထွေးသောအခြေအနေအချို့၏မျှော်လင့်ချက်ကို ပိုမိုတိကျစွာအကောင်အထည်ဖော်နိုင်စေပါသည်။ .NET မှာက မပြည့်စုံဘူး ဆိုတော့ သီအိုရီအရ၊ တစ်မျိုးတည်းတွင်မဟုတ်ဘဲ ကိန်းရှင်များစွာ (Posix Threads ကဲ့သို့) တွင် တန်းစီခြင်းများစွာရှိသင့်သည်။ ထို့နောက် ဒဿနပညာရှင်အားလုံးအတွက် ၎င်းတို့ကို ဖန်တီးနိုင်မည်ဖြစ်သည်။ သို့သော် ဤပုံစံတွင်ပင်၊ ကုဒ်ကို လျှော့ချနိုင်သည်။

ဒဿနပညာရှင်များစွာ သို့မဟုတ် async / await

အိုကေ၊ ယခု ကျွန်ုပ်တို့သည် စာတွဲများကို ထိထိရောက်ရောက် ပိတ်ဆို့နိုင်ပါပြီ။ သို့သော် ကျွန်ုပ်တို့တွင် ဒဿနပညာရှင်များစွာရှိလျှင်ကော။ 100? 10000? ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် ဝဘ်ဆာဗာသို့ တောင်းဆိုချက် 100000 ကို လက်ခံရရှိခဲ့သည်။ တောင်းဆိုမှုတစ်ခုစီအတွက် စာတွဲတစ်ခုဖန်တီးရန်မှာ ပေါ်နေမည်ဖြစ်သောကြောင့်၊ ဤမျှလောက်များစွာသော threads သည်အပြိုင်အလုပ်လုပ်မည်မဟုတ်ပါ။ logical cores များသလောက်သာ လည်ပတ်ပါမည် (ငါ့တွင် 4)။ တခြားလူတိုင်းက အရင်းအမြစ်တွေကို သိမ်းသွားလိမ့်မယ်။ ဤပြဿနာအတွက် အဖြေတစ်ခုမှာ async/ait pattern ဖြစ်သည်။ ၎င်း၏ အယူအဆမှာ ၎င်းသည် ဆက်ရန် တစ်ခုခုကို စောင့်ရန် လိုအပ်ပါက လုပ်ဆောင်ချက်သည် thread ကို မကိုင်ထားပေ။ တစ်ခုခုလုပ်သောအခါ၊ ၎င်းသည် ၎င်း၏ ကွပ်မျက်မှုကို ပြန်လည်စတင်သည် (သို့သော် တစ်ခုတည်းသော thread တွင် မလိုအပ်ပါ။) ငါတို့ကိစ္စမှာ၊ ငါတို့လမ်းခွဲကိုစောင့်လိမ့်မယ်။

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 နှင့် သင်လုပ်ဆောင်နိုင်သည့် အခြားအရာအားလုံးကို စောင့်ဆိုင်းနိုင်သည်။ နည်းလမ်းအတွင်းတွင်၊ state machine သည် လုပ်ဆောင်မှုကို ထိန်းချုပ်သည်။ အဓိကအချက်မှာ နှောင့်နှေးခြင်းမရှိပါက၊ ကွပ်မျက်မှုသည် တစ်ပြိုင်နက်တည်းဖြစ်ပြီး ရှိလျှင် thread သည် ထွက်လာမည်ဖြစ်သည်။ ဒါကို ပိုနားလည်ဖို့အတွက် ဒီ state machine ကိုကြည့်တာ ပိုကောင်းပါတယ်။ ဤအရာများမှ ကွင်းဆက်များကို သင်ဖန်တီးနိုင်သည်။ async / await နည်းလမ်းများ။

စမ်းကြည့်ရအောင်။ တွေးခေါ်ပညာရှင် အယောက် 100 သည် ယုတ္တိဗေဒ cores လေးခုပါသော စက်တစ်ခုပေါ်တွင် 4 စက္ကန့်ကြာ အလုပ်လုပ်သည်။ Monitor ဖြင့် ယခင်ဖြေရှင်းချက်သည် ပထမအဆက် 8 ခုသာ လုပ်ဆောင်ခဲ့ပြီး ကျန်သည် လုံးဝမလည်ပတ်ပါ။ ဤစာတွဲ 4 ခုစီသည် 4ms ခန့် ရပ်နားထားသည်။ နှင့် async/ait solution သည် ပျမ်းမျှ 2 စက္ကန့်စီ စောင့်ဆိုင်းခြင်းဖြင့် 100 လုံး အလုပ်လုပ်ပါသည်။ မှန်ပါသည်၊ စစ်မှန်သောစနစ်များတွင် 6.8 စက္ကန့်ကြာမျှ ပျင်းရိခြင်းသည် လက်ခံနိုင်ဖွယ်မရှိသည့်အပြင် ဤကဲ့သို့သော တောင်းဆိုမှုများကို မလုပ်ဆောင်ခြင်းသည် ပိုကောင်းပါသည်။ Monitor ဖြင့်ဖြေရှင်းချက်သည် အတိုင်းအတာတစ်ခုအထိ မဖြစ်နိုင်တော့ပေ။

ကောက်ချက်

ဤနမူနာငယ်များမှ သင်တွေ့မြင်နိုင်သည်အတိုင်း၊ .NET သည် ထပ်တူပြုမှုတည်ဆောက်ပုံများစွာကို ပံ့ပိုးပေးပါသည်။ သို့သော် ၎င်းတို့ကို မည်သို့အသုံးပြုရမည်ကို အမြဲမသိသာပေ။ ဒီဆောင်းပါးက အထောက်အကူဖြစ်မယ်လို့ မျှော်လင့်ပါတယ်။ ယခုအချိန်တွင်၊ ဤသည်မှာ အဆုံးဖြစ်သည်၊ သို့သော် စိတ်ဝင်စားစရာများစွာ ကျန်နေသေးသည်၊ ဥပမာ၊ thread-safe collections၊ TPL Dataflow၊ Reactive programming၊ Software Transaction model စသည်ဖြင့်။

သတင်းရင်းမြစ်

• စီးဆင်းမှုကို ပုံဖော်ခြင်း- Concurrency Visualizer
• MSDN- အသွားအလာ, Asynchronous programming ပုံစံများ နှင့်များစွာသောအခြား အခြား
• [Richter] - C# မှတဆင့် CLR၊ Jeffrey Richter
• [Eric Lippert] - သော့ခတ်ခြင်းအကြောင်း
• အရင်းအမြစ်
• ရုပ်ပုံ - "ဓားများကြားကအက", G. Semiradsky

source: www.habr.com