Well-Fed Philosophers ຫຼື Competitive .NET Programming

ໃຫ້ພວກເຮົາເບິ່ງວິທີການດໍາເນີນໂຄງການພ້ອມກັນແລະຂະຫນານໃນ .Net, ການນໍາໃຊ້ບັນຫາອາຫານຂອງ Philosophers ເປັນຕົວຢ່າງ. ແຜນການແມ່ນນີ້, ຈາກ synchronization ຂອງກະທູ້ / ຂະບວນການ, ກັບຕົວແບບນັກສະແດງ (ໃນພາກສ່ວນດັ່ງຕໍ່ໄປນີ້). ບົດຄວາມອາດຈະເປັນປະໂຫຍດສໍາລັບຄົນຮູ້ຈັກທໍາອິດຫຼືເພື່ອເຮັດໃຫ້ຄວາມຮູ້ຂອງທ່ານສົດຊື່ນ.

ເປັນຫຍັງມັນທັງຫມົດ? Transistors ບັນລຸຂະຫນາດຕໍາ່ສຸດທີ່ຂອງເຂົາເຈົ້າ, ກົດຫມາຍ Moore ພັກຜ່ອນກ່ຽວກັບການຈໍາກັດຄວາມໄວຂອງແສງສະຫວ່າງແລະດັ່ງນັ້ນການເພີ່ມຂຶ້ນແມ່ນສັງເກດເຫັນໃນຈໍານວນ, transistors ຫຼາຍສາມາດເຮັດໄດ້. ໃນເວລາດຽວກັນ, ຈໍານວນຂໍ້ມູນກໍາລັງເຕີບໂຕ, ແລະຜູ້ໃຊ້ຄາດຫວັງວ່າການຕອບສະຫນອງທັນທີຈາກລະບົບຕ່າງໆ. ໃນສະຖານະການດັ່ງກ່າວ, ການຂຽນໂປລແກລມ "ປົກກະຕິ", ເມື່ອພວກເຮົາມີກະທູ້ປະຕິບັດຫນຶ່ງ, ບໍ່ມີປະສິດຕິຜົນອີກຕໍ່ໄປ. ທ່ານຈໍາເປັນຕ້ອງໄດ້ແກ້ໄຂ somehow ບັນຫາຂອງການປະຕິບັດພ້ອມໆກັນຫຼື concurrent. ຍິ່ງໄປກວ່ານັ້ນ, ບັນຫານີ້ມີຢູ່ໃນລະດັບຕ່າງໆ: ໃນລະດັບຂອງກະທູ້, ລະດັບຂະບວນການ, ໃນລະດັບເຄື່ອງຈັກໃນເຄືອຂ່າຍ (ລະບົບການແຈກຢາຍ). .NET ມີເທກໂນໂລຍີທີ່ມີເວລາທົດສອບຄຸນນະພາບສູງເພື່ອແກ້ໄຂບັນຫາດັ່ງກ່າວໄດ້ໄວ ແລະມີປະສິດທິພາບ.

ຈຸດປະສົງ

Edsger Dijkstra posed ບັນຫານີ້ກັບນັກຮຽນລາວໃນຕົ້ນປີ 1965. ຮູບແບບການສ້າງຕັ້ງຂຶ້ນແມ່ນດັ່ງຕໍ່ໄປນີ້. ມີນັກປັດຊະຍາທີ່ແນ່ນອນ (ປົກກະຕິແລ້ວຫ້າ) ແລະຕົວເລກດຽວກັນຂອງສ້ອມ. ເຂົາເຈົ້ານັ່ງຢູ່ໂຕະມົນ, ມີສ້ອມລະຫວ່າງເຂົາເຈົ້າ. ນັກປັດຊະຍາສາມາດກິນອາຫານຈາກຈານອາຫານທີ່ບໍ່ມີທີ່ສິ້ນສຸດ, ຄິດຫຼືລໍຖ້າ. ເພື່ອກິນນັກປັດຊະຍາ, ທ່ານຈໍາເປັນຕ້ອງເອົາສອງສ້ອມ (ຄົນສຸດທ້າຍແບ່ງປັນສ້ອມກັບຄັ້ງທໍາອິດ). ການຍົກຂຶ້ນ ແລະວາງລົງທາງສ້ອມແມ່ນສອງການກະທໍາທີ່ແຍກຕ່າງຫາກ. ນັກປັດຊະຍາທັງໝົດແມ່ນມິດງຽບ. ວຽກງານແມ່ນເພື່ອຊອກຫາສູດການຄິດໄລ່ດັ່ງກ່າວທີ່ທັງຫມົດຂອງພວກເຂົາຈະຄິດແລະເຕັມທີ່ເຖິງແມ່ນວ່າຫຼັງຈາກ 54 ປີ.

ທໍາອິດ, ໃຫ້ພະຍາຍາມແກ້ໄຂບັນຫານີ້ໂດຍຜ່ານການນໍາໃຊ້ພື້ນທີ່ຮ່ວມກັນ. ສ້ອມນອນຢູ່ເທິງໂຕະທົ່ວໄປ ແລະນັກປັດຊະຍາພຽງແຕ່ເອົາພວກມັນເມື່ອພວກເຂົາຢູ່ແລ້ວເອົາຄືນ. ທີ່ນີ້ມີບັນຫາກັບ synchronization, ໃນເວລາທີ່ແນ່ນອນທີ່ຈະເອົາ surebets? ຈະເປັນແນວໃດຖ້າບໍ່ມີສ້ອມ? ແລະອື່ນໆ ແຕ່ທໍາອິດ, ໃຫ້ເລີ່ມຕົ້ນຂອງ philosophers ໄດ້.

ເພື່ອເລີ່ມຕົ້ນ threads, ພວກເຮົາໃຊ້ 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. ສະລອຍນ້ຳນີ້ມີແຖວທີ່ມີໜ້າວຽກ ແລະ CLR ສ້າງ ຫຼືລຶບກະທູ້ຂຶ້ນກັບຈຳນວນຂອງໜ້າວຽກເຫຼົ່ານີ້. ສະນຸກເກີດຽວສໍາລັບ AppDomains ທັງຫມົດ. ສະນຸກເກີນີ້ຄວນຈະຖືກນໍາໃຊ້ເກືອບສະເຫມີ, ເພາະວ່າ. ບໍ່ຈໍາເປັນຕ້ອງລົບກວນການສ້າງ, ລຶບກະທູ້, ແຖວຂອງເຂົາເຈົ້າ, ແລະອື່ນໆ. ມັນເປັນໄປໄດ້ໂດຍບໍ່ມີການສະນຸກເກີ, ແຕ່ຫຼັງຈາກນັ້ນທ່ານຕ້ອງໃຊ້ມັນໂດຍກົງ. Thread, ນີ້ແມ່ນເປັນປະໂຫຍດສໍາລັບກໍລະນີທີ່ທ່ານຈໍາເປັນຕ້ອງມີການປ່ຽນແປງບູລິມະສິດຂອງ thread, ໃນເວລາທີ່ພວກເຮົາມີການດໍາເນີນງານຍາວ, ສໍາລັບຫົວຂໍ້ Foreground, ແລະອື່ນໆ.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, System.Threading.Tasks.Task ຫ້ອງຮຽນແມ່ນຄືກັນ Thread, ແຕ່ມີທຸກປະເພດຂອງຄວາມສະດວກ: ຄວາມສາມາດໃນການດໍາເນີນການວຽກງານຫຼັງຈາກຕັນຂອງວຽກງານອື່ນໆ, ກັບຄືນໃຫ້ເຂົາເຈົ້າຈາກຫນ້າທີ່, ສະດວກຂັດຂວາງພວກເຂົາ, ແລະອື່ນໆ. ແລະອື່ນໆ.ພວກເຂົາມີຄວາມຈໍາເປັນເພື່ອສະຫນັບສະຫນູນ async / ລໍຖ້າການກໍ່ສ້າງ (Task-based Asynchronous Pattern, ້ໍາຕານ syntactic ສໍາລັບການລໍຖ້າການດໍາເນີນງານ 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();
    }
}

ໃນທີ່ນີ້ພວກເຮົາທໍາອິດພະຍາຍາມເອົາສ້ອມຊ້າຍ, ແລະຫຼັງຈາກນັ້ນສ້ອມຂວາ, ແລະຖ້າຫາກວ່າມັນເຮັດວຽກອອກ, ຫຼັງຈາກນັ້ນພວກເຮົາກິນອາຫານແລະໃຫ້ເຂົາເຈົ້າກັບຄືນໄປບ່ອນ. ເອົາຫນຶ່ງສ້ອມແມ່ນປະລໍາມະນູ, i.e. ສອງກະທູ້ບໍ່ສາມາດເອົາຫນຶ່ງໃນເວລາດຽວກັນ (ບໍ່ຖືກຕ້ອງ: ທໍາອິດອ່ານວ່າສ້ອມແມ່ນບໍ່ເສຍຄ່າ, ທີສອງ - ເຊັ່ນດຽວກັນ, ທໍາອິດໃຊ້ເວລາ, ທີສອງໃຊ້ເວລາ). ສໍາລັບການນີ້ Interlocked.CompareExchange, ເຊິ່ງຕ້ອງໄດ້ຮັບການປະຕິບັດດ້ວຍຄໍາແນະນໍາຂອງໂປເຊດເຊີ (TSL, XCHG), ເຊິ່ງ locks ຊິ້ນສ່ວນຂອງຄວາມຊົງຈໍາສໍາລັບການອ່ານລໍາດັບປະລໍາມະນູແລະການຂຽນ. ແລະ SpinWait ແມ່ນທຽບເທົ່າກັບການກໍ່ສ້າງ while(true) ພຽງແຕ່ມີ "magic" ເລັກນ້ອຍ - ກະທູ້ໃຊ້ເວລາໂຮງງານຜະລິດ (Thread.SpinWait), ແຕ່​ບາງ​ຄັ້ງ​ການ​ໂອນ​ການ​ຄວບ​ຄຸມ​ກັບ​ກະ​ທູ້​ອື່ນ (Thread.Yeild) ຫຼື​ນອນ​ຫລັບ (Thread.Sleep).

ແຕ່ການແກ້ໄຂນີ້ບໍ່ໄດ້ຜົນ, ເພາະວ່າ ການໄຫຼເຂົ້າໃນໄວໆນີ້ (ສໍາລັບຂ້ອຍພາຍໃນຫນຶ່ງວິນາທີ) ໄດ້ຖືກສະກັດ: ນັກປັດຊະຍາທັງຫມົດໃຊ້ສ້ອມຊ້າຍຂອງເຂົາເຈົ້າ, ແຕ່ບໍ່ແມ່ນທີ່ຖືກຕ້ອງ. array ຂອງສ້ອມມີຄ່າ: 1 2 3 4 5.

ໃນຮູບ, ບລັອກກະທູ້ (deadlock). ສີຂຽວ - ການປະຕິບັດ, ສີແດງ - synchronization, ສີຂີ້ເຖົ່າ - ກະທູ້ແມ່ນນອນ. rhombuses ຊີ້ບອກເວລາເລີ່ມຕົ້ນຂອງ 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)
    );
}

ສິ່ງທີ່ສໍາຄັນກ່ຽວກັບລະຫັດນີ້ແມ່ນວ່ານັກປັດຊະຍາສອງຄົນໃນສີ່ຄົນລືມເອົາທາງແຍກຊ້າຍຂອງພວກເຂົາລົງ. ແລະມັນ turns ໃຫ້ເຫັນວ່າພວກເຂົາກິນອາຫານຫຼາຍ, ໃນຂະນະທີ່ຄົນອື່ນເລີ່ມຫິວ, ເຖິງແມ່ນວ່າກະທູ້ມີບູລິມະສິດດຽວກັນ. ໃນທີ່ນີ້ພວກເຂົາບໍ່ໄດ້ອຶດຫິວຢ່າງສົມບູນ, ເພາະວ່າ. ນັກປັດຊະຍາທີ່ບໍ່ດີເຮັດໃຫ້ສ້ອມຂອງເຂົາເຈົ້າຄືນບາງຄັ້ງ. ປະກົດວ່າຄົນດີກິນໜ້ອຍກວ່າຄົນບໍ່ດີປະມານ 5 ເທົ່າ. ດັ່ງນັ້ນຄວາມຜິດພາດຂະຫນາດນ້ອຍໃນລະຫັດນໍາໄປສູ່ການຫຼຸດລົງໃນການປະຕິບັດ. ມັນຍັງເປັນມູນຄ່າທີ່ສັງເກດວ່າສະຖານະການທີ່ຫາຍາກແມ່ນເປັນໄປໄດ້ເມື່ອນັກປັດຊະຍາທັງຫມົດໃຊ້ສ້ອມຊ້າຍ, ບໍ່ມີຂວາ, ພວກເຂົາເອົາຊ້າຍ, ລໍຖ້າ, ເອົາຊ້າຍອີກເທື່ອຫນຶ່ງ, ແລະອື່ນໆ. ສະຖານະການນີ້ຍັງເປັນຄວາມອຶດຫິວ, ຄືກັບຄວາມຕາຍ. ຂ້ອຍລົ້ມເຫລວໃນການເຮັດຊ້ໍາມັນ. ຂ້າງລຸ່ມນີ້ແມ່ນຮູບສໍາລັບສະຖານະການທີ່ນັກປັດຊະຍາທີ່ບໍ່ດີສອງຄົນໄດ້ເອົາທັງສອງສ້ອມແລະສອງຄົນດີກໍາລັງຫິວໂຫຍ.

ໃນທີ່ນີ້ທ່ານສາມາດເຫັນໄດ້ວ່າກະທູ້ຕື່ນຂຶ້ນບາງຄັ້ງແລະພະຍາຍາມເອົາຊັບພະຍາກອນ. ສອງຂອງສີ່ແກນບໍ່ເຮັດຫຍັງເລີຍ (ເສັ້ນສະແດງສີຂຽວຂ້າງເທິງ).

ການເສຍຊີວິດຂອງນັກປັດຊະຍາ

ແລ້ວ, ບັນຫາອີກຢ່າງຫນຶ່ງທີ່ສາມາດຂັດຂວາງການກິນເຂົ້າແລງອັນຮຸ່ງໂລດຂອງນັກປັດຊະຍາແມ່ນຖ້າຫນຶ່ງໃນພວກມັນຕາຍທັນທີທັນໃດດ້ວຍສ້ອມຢູ່ໃນມືຂອງລາວ (ແລະພວກເຂົາຈະຝັງລາວແບບນັ້ນ). ຫຼັງຈາກນັ້ນ, ປະເທດເພື່ອນບ້ານຈະຖືກປະໄວ້ໂດຍບໍ່ມີອາຫານຄ່ໍາ. ທ່ານສາມາດມາພ້ອມກັບລະຫັດຕົວຢ່າງສໍາລັບກໍລະນີນີ້ຕົວທ່ານເອງ, ຕົວຢ່າງ, ມັນຖືກຖິ້ມອອກ NullReferenceException ຫຼັງຈາກ philosopher ໃຊ້ເວລາສ້ອມ. ແລະ, ໂດຍວິທີທາງການ, ຂໍ້ຍົກເວັ້ນຈະບໍ່ຖືກຈັດການແລະລະຫັດການໂທຈະບໍ່ພຽງແຕ່ຈັບມັນ (ສໍາລັບການນີ້ AppDomain.CurrentDomain.UnhandledException ແລະ ອື່ນໆ). ເພາະສະນັ້ນ, ການຈັດການຄວາມຜິດພາດແມ່ນຈໍາເປັນໃນກະທູ້ຕົວເອງແລະດ້ວຍການຢຸດເຊົາຢ່າງສະຫງ່າງາມ.

The waiter

ຕົກລົງ, ພວກເຮົາຈະແກ້ໄຂບັນຫາການຢຸດຊະງັກ, ຄວາມອຶດຫິວ, ແລະຄວາມຕາຍນີ້ແນວໃດ? ພວກເຮົາຈະອະນຸຍາດໃຫ້ນັກປັດຊະຍາພຽງຄົນດຽວເຂົ້າຫາທາງສ້ອມ, ເພີ່ມການຍົກເວັ້ນເຊິ່ງກັນແລະກັນຂອງກະທູ້ສໍາລັບສະຖານທີ່ນີ້. ເຮັດແນວໃດມັນ? ສົມມຸດວ່າຜູ້ຮັບໃຊ້ຢືນຢູ່ຂ້າງນັກປັດຊະຍາ, ຜູ້ທີ່ອະນຸຍາດໃຫ້ນັກປັດຊະຍາຄົນໃດຄົນຫນຶ່ງເອົາສ້ອມ. ເຮັດແນວໃດພວກເຮົາເຮັດໃຫ້ waiter ນີ້ແລະ philosophers ຈະຖາມເຂົາ, ຄໍາຖາມແມ່ນຫນ້າສົນໃຈ.

ວິທີທີ່ງ່າຍດາຍທີ່ສຸດແມ່ນເວລາທີ່ນັກປັດຊະຍາພຽງແຕ່ຈະຂໍໃຫ້ຜູ້ຮັບໃຊ້ຢູ່ສະເຫມີສໍາລັບການເຂົ້າເຖິງສ້ອມ. ເຫຼົ່ານັ້ນ. ໃນປັດຈຸບັນນັກປັດຊະຍາຈະບໍ່ລໍຖ້າສໍາລັບສ້ອມຢູ່ໃກ້ໆ, ແຕ່ລໍຖ້າຫຼືຖາມຜູ້ລໍຖ້າ. ໃນຕອນທໍາອິດ, ພວກເຮົາໃຊ້ພຽງແຕ່ User Space ສໍາລັບການນີ້, ໃນມັນພວກເຮົາບໍ່ໃຊ້ການຂັດຂວາງເພື່ອໂທຫາຂັ້ນຕອນໃດໆຈາກແກ່ນ (ກ່ຽວກັບພວກມັນຂ້າງລຸ່ມນີ້).

ການແກ້ໄຂໃນພື້ນທີ່ຜູ້ໃຊ້

ໃນທີ່ນີ້ພວກເຮົາຈະເຮັດເຊັ່ນດຽວກັນກັບພວກເຮົາເຄີຍເຮັດກັບຫນຶ່ງສ້ອມແລະສອງນັກປັດຊະຍາ, ພວກເຮົາຈະ spin ໃນວົງຈອນແລະລໍຖ້າ. ແຕ່ໃນປັດຈຸບັນມັນຈະເປັນນັກປັດຊະຍາທັງຫມົດແລະ, ດັ່ງທີ່ມັນແມ່ນ, ພຽງແຕ່ຫນຶ່ງສ້ອມ, i.e. ມັນສາມາດເວົ້າໄດ້ວ່າມີພຽງແຕ່ນັກປັດຊະຍາທີ່ເອົາ "ສ້ອມທອງ" ນີ້ຈາກ waiter ທີ່ຈະກິນອາຫານ. ສໍາລັບນີ້ພວກເຮົາໃຊ້ 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; }, ແຕ່ມີ "magic" ຫຼາຍກວ່າໃນ SpinWait (ທີ່ຖືກນໍາໃຊ້ຢູ່ທີ່ນັ້ນ). ບັດ​ນີ້​ລາວ​ຮູ້​ວິທີ​ນັບ​ຄົນ​ທີ່​ລໍ​ຖ້າ, ເຮັດ​ໃຫ້​ເຂົາ​ເຈົ້າ​ນອນ​ໜ້ອຍ​ໜຶ່ງ, ແລະ​ອື່ນໆ. ແລະອື່ນໆ. ໂດຍທົ່ວໄປ, ເຮັດທຸກສິ່ງທຸກຢ່າງທີ່ເປັນໄປໄດ້ເພື່ອເພີ່ມປະສິດທິພາບ. ແຕ່ພວກເຮົາຕ້ອງຈື່ໄວ້ວ່ານີ້ຍັງຄົງເປັນວົງຈອນການເຄື່ອນໄຫວດຽວກັນທີ່ກິນເຖິງຊັບພະຍາກອນຂອງໂປເຊດເຊີແລະຮັກສາການໄຫຼເຂົ້າ, ເຊິ່ງສາມາດນໍາໄປສູ່ຄວາມອຶດຫິວຖ້ານັກປັດຊະຍາຄົນຫນຶ່ງກາຍເປັນບູລິມະສິດຫຼາຍກ່ວາຄົນອື່ນ, ແຕ່ບໍ່ມີສ້ອມທອງ (ບັນຫາ Priority Inversion) . ດັ່ງນັ້ນ, ພວກເຮົາໃຊ້ມັນພຽງແຕ່ສໍາລັບການປ່ຽນແປງທີ່ສັ້ນຫຼາຍໃນຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນ, ໂດຍບໍ່ມີການໂທຫາພາກສ່ວນທີສາມ, locks ຮັງ, ແລະຄວາມແປກໃຈອື່ນໆ.

ແຕ້ມສໍາລັບ SpinLock. ສາຍນ້ໍາແມ່ນ "ຕໍ່ສູ້" ຢ່າງຕໍ່ເນື່ອງສໍາລັບຄວາມຍາວຂອງສ້ອມທອງ. ມີຄວາມລົ້ມເຫລວ - ໃນຮູບ, ພື້ນທີ່ທີ່ເລືອກ. ຫຼັກບໍ່ໄດ້ຖືກນໍາໃຊ້ຢ່າງເຕັມສ່ວນ: ພຽງແຕ່ປະມານ 2/3 ໂດຍສີ່ກະທູ້ເຫຼົ່ານີ້.

ການແກ້ໄຂອີກອັນຫນຶ່ງຢູ່ທີ່ນີ້ແມ່ນການນໍາໃຊ້ເທົ່ານັ້ນ Interlocked.CompareExchange ດ້ວຍການລໍຖ້າຢ່າງຫ້າວຫັນດຽວກັນທີ່ສະແດງຢູ່ໃນລະຫັດຂ້າງເທິງ (ໃນນັກປັດຊະຍາທີ່ອຶດຫິວ), ແຕ່ນີ້, ດັ່ງທີ່ໄດ້ກ່າວມາແລ້ວ, ໃນທາງທິດສະດີສາມາດນໍາໄປສູ່ການຂັດຂວາງ.

ກ່ຽວກັບ Interlocked ຄວນສັງເກດວ່າມີບໍ່ພຽງແຕ່ CompareExchange, ແຕ່ຍັງວິທີການອື່ນໆສໍາລັບການປະລໍາມະນູອ່ານແລະຂຽນ. ແລະໂດຍຜ່ານການຊ້ໍາກັນຂອງການປ່ຽນແປງ, ໃນກໍລະນີທີ່ກະທູ້ອື່ນມີເວລາທີ່ຈະເຮັດການປ່ຽນແປງຂອງມັນ (ອ່ານ 1, ອ່ານ 2, ຂຽນ 2, ຂຽນ 1 ແມ່ນບໍ່ດີ), ມັນສາມາດຖືກນໍາໃຊ້ສໍາລັບການປ່ຽນແປງທີ່ສັບສົນກັບຄ່າດຽວ (Interlocked Anything pattern) .

ການແກ້ໄຂຮູບແບບ Kernel

ເພື່ອຫຼີກເວັ້ນການສູນເສຍຊັບພະຍາກອນໃນວົງ, ໃຫ້ເບິ່ງວ່າພວກເຮົາສາມາດບລັອກກະທູ້ໄດ້ແນວໃດ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ສືບຕໍ່ຕົວຢ່າງຂອງພວກເຮົາ, ໃຫ້ພວກເຮົາເບິ່ງວິທີການ waiter ເຮັດໃຫ້ philosopher ນອນແລະ wakes ລາວພຽງແຕ່ໃນເວລາທີ່ຈໍາເປັນ. ທໍາອິດ, ໃຫ້ເບິ່ງວິທີການເຮັດສິ່ງນີ້ໂດຍຜ່ານຮູບແບບ kernel ຂອງລະບົບປະຕິບັດການ. ໂຄງສ້າງທັງຫມົດຢູ່ທີ່ນັ້ນມັກຈະຊ້າກວ່າຢູ່ໃນພື້ນທີ່ຂອງຜູ້ໃຊ້. ຕົວຢ່າງຊ້າລົງຫຼາຍຄັ້ງ AutoResetEvent ອາດຈະຊ້າກວ່າ 53 ເທົ່າ SpinLock [ຣິກເຕີ]. ແຕ່ດ້ວຍການຊ່ວຍເຫຼືອຂອງພວກເຂົາ, ທ່ານສາມາດ synchronize ຂະບວນການໃນທົ່ວລະບົບ, ຈັດການຫຼືບໍ່.

ການກໍ່ສ້າງພື້ນຖານຢູ່ທີ່ນີ້ແມ່ນ semaphore ທີ່ສະເຫນີໂດຍ Dijkstra ຫຼາຍກວ່າເຄິ່ງຫນຶ່ງສະຕະວັດກ່ອນຫນ້ານີ້. A semaphore ແມ່ນ, ເວົ້າງ່າຍໆ, ເປັນຈໍານວນບວກທີ່ຄຸ້ມຄອງໂດຍລະບົບ, ແລະການປະຕິບັດສອງຢ່າງກ່ຽວກັບມັນ, ເພີ່ມແລະຫຼຸດລົງ. ຖ້າມັນຫຼຸດລົງ, ສູນ, ຫຼັງຈາກນັ້ນກະທູ້ການໂທຈະຖືກບລັອກ. ເມື່ອຕົວເລກຖືກເພີ່ມຂຶ້ນໂດຍກະທູ້ / ຂະບວນການອື່ນໆທີ່ມີການເຄື່ອນໄຫວ, ຫຼັງຈາກນັ້ນກະທູ້ຖືກຂ້າມແລະ semaphore ຖືກຫຼຸດລົງອີກເທື່ອຫນຶ່ງໂດຍຈໍານວນທີ່ຜ່ານ. ຄົນເຮົາສາມາດຈິນຕະນາການລົດໄຟຢູ່ໃນຄໍຂວດທີ່ມີ semaphore. .NET ສະເຫນີໂຄງສ້າງຫຼາຍຢ່າງທີ່ມີຫນ້າທີ່ຄ້າຍຄືກັນ: AutoResetEvent, ManualResetEvent, Mutex ແລະຕົວຂ້ອຍເອງ Semaphore. ພວກເຮົາຈະນໍາໃຊ້ AutoResetEvent, ນີ້ແມ່ນງ່າຍດາຍທີ່ສຸດຂອງການກໍ່ສ້າງເຫຼົ່ານີ້: ພຽງແຕ່ສອງຄ່າ 0 ແລະ 1 (false, true). ວິທີການຂອງນາງ WaitOne() ບລັອກກະທູ້ການໂທຖ້າຄ່າແມ່ນ 0, ແລະຖ້າ 1, ຫຼຸດລົງເປັນ 0 ແລະຂ້າມມັນ. ວິທີການ Set() ເພີ່ມຂຶ້ນເປັນ 1 ແລະໃຫ້ຜູ້ຮັບໃຊ້ຫນຶ່ງຜ່ານ, ຜູ້ທີ່ອີກເທື່ອຫນຶ່ງຫຼຸດລົງເປັນ 0. ປະຕິບັດຄ້າຍຄື turnstile ລົດໄຟໃຕ້ດິນ.

ຂໍໃຫ້ສັບສົນການແກ້ໄຂແລະນໍາໃຊ້ລັອກສໍາລັບນັກປັດຊະຍາແຕ່ລະຄົນ, ແລະບໍ່ແມ່ນສໍາລັບທັງຫມົດໃນເວລາດຽວກັນ. ເຫຼົ່ານັ້ນ. ໃນປັດຈຸບັນສາມາດມີນັກປັດຊະຍາຫຼາຍຄົນໃນເວລາດຽວກັນ, ແລະບໍ່ແມ່ນຫນຶ່ງ. ແຕ່ພວກເຮົາອີກເທື່ອຫນຶ່ງຕັນການເຂົ້າເຖິງຕາຕະລາງເພື່ອໃຫ້ຖືກຕ້ອງ, ຫຼີກເວັ້ນການເຊື້ອຊາດ (ເງື່ອນໄຂເຊື້ອຊາດ), ໃຫ້ແນ່ໃຈວ່າການbets.

// Для блокирования отдельного философа.
// Инициализируется: 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();
}

ເພື່ອເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນຢູ່ທີ່ນີ້, ພິຈາລະນາກໍລະນີທີ່ນັກປັດຊະຍາລົ້ມເຫລວໃນການສ້ອມແຊມ, ຫຼັງຈາກນັ້ນການກະທໍາຂອງລາວຈະເປັນດັ່ງຕໍ່ໄປນີ້. ລາວກໍາລັງລໍຖ້າການເຂົ້າເຖິງຕາຕະລາງ. ເມື່ອໄດ້ຮັບມັນ, ລາວພະຍາຍາມເອົາສ້ອມ. ບໍ່ໄດ້ຜົນ. ມັນໃຫ້ການເຂົ້າເຖິງຕາຕະລາງ (ການຍົກເວັ້ນເຊິ່ງກັນແລະກັນ). ແລະຜ່ານ "turnstile" ຂອງລາວ (AutoResetEvent) (ພວກເຂົາເປີດໃນເບື້ອງຕົ້ນ). ມັນເຂົ້າໄປໃນວົງຈອນອີກເທື່ອຫນຶ່ງ, ເພາະວ່າ ລາວບໍ່ມີສ້ອມ. ລາວພະຍາຍາມເອົາພວກມັນແລະຢຸດຢູ່ "turnstile" ຂອງລາວ. ບາງປະເທດເພື່ອນບ້ານທີ່ໂຊກດີຫຼາຍທາງດ້ານຂວາຫຼືຊ້າຍ, ກິນອາຫານສໍາເລັດຮູບ, ປົດລັອກນັກປັດຊະຍາຂອງພວກເຮົາ, "ເປີດ turnstile ລາວ." ນັກປັດຊະຍາຂອງພວກເຮົາຜ່ານມັນ (ແລະມັນປິດຢູ່ຫລັງມັນ) ເປັນຄັ້ງທີສອງ. ລາວພະຍາຍາມເປັນຄັ້ງທີສາມເພື່ອເອົາສ້ອມ. ໂຊກ​ດີ. ແລະລາວຜ່ານ turnstile ລາວເພື່ອຮັບປະທານອາຫານ.

ເມື່ອມີຂໍ້ຜິດພາດແບບສຸ່ມໃນລະຫັດດັ່ງກ່າວ (ພວກມັນມີຢູ່ສະເຫມີ), ຕົວຢ່າງ, ເພື່ອນບ້ານຖືກລະບຸບໍ່ຖືກຕ້ອງຫຼືວັດຖຸດຽວກັນຖືກສ້າງຂື້ນ. AutoResetEvent ສໍາລັບທຸກຄົນ (Enumerable.Repeat), ຫຼັງຈາກນັ້ນ philosophers ຈະໄດ້ຮັບການລໍຖ້າສໍາລັບນັກພັດທະນາ, ເນື່ອງຈາກວ່າ ການຊອກຫາຂໍ້ຜິດພາດໃນລະຫັດດັ່ງກ່າວແມ່ນຂ້ອນຂ້າງເປັນວຽກທີ່ຍາກ. ບັນຫາອີກອັນຫນຶ່ງຂອງການແກ້ໄຂນີ້ແມ່ນວ່າມັນບໍ່ຮັບປະກັນວ່ານັກປັດຊະຍາບາງຄົນຈະບໍ່ຫິວ.

ວິທີແກ້ໄຂແບບປະສົມ

ພວກເຮົາໄດ້ເບິ່ງສອງວິທີການກໍານົດເວລາ, ໃນເວລາທີ່ພວກເຮົາຢູ່ໃນໂຫມດຜູ້ໃຊ້ແລະ loop, ແລະໃນເວລາທີ່ພວກເຮົາຕັນ thread ຜ່ານ kernel. ວິທີທໍາອິດແມ່ນດີສໍາລັບ locks ສັ້ນ, ທີສອງສໍາລັບຍາວ. ມັນມັກຈະມີຄວາມຈໍາເປັນທໍາອິດລໍຖ້າໄລຍະສັ້ນໆສໍາລັບຕົວແປທີ່ມີການປ່ຽນແປງໃນ loop, ແລະຫຼັງຈາກນັ້ນສະກັດ thread ໃນເວລາທີ່ລໍຖ້າແມ່ນຍາວ. ວິທີການນີ້ແມ່ນປະຕິບັດໃນອັນທີ່ເອີ້ນວ່າ. ໂຄງສ້າງປະສົມ. ນີ້ແມ່ນໂຄງສ້າງດຽວກັນກັບໂຫມດ kernel, ແຕ່ຕອນນີ້ມີຮູບແບບຜູ້ໃຊ້: SemaphorSlim, ManualResetEventSlim ແລະອື່ນໆ ການອອກແບບທີ່ນິຍົມຫຼາຍທີ່ສຸດຢູ່ທີ່ນີ້ແມ່ນ Monitor, ເນື່ອງຈາກວ່າ ໃນ C # ມີຊື່ສຽງ lock syntax. Monitor ນີ້ແມ່ນ semaphore ດຽວກັນກັບຄ່າສູງສຸດຂອງ 1 (mutex), ແຕ່ສະຫນັບສະຫນູນສໍາລັບການລໍຖ້າໃນ loop, recursion, ຮູບແບບການປ່ຽນແປງເງື່ອນໄຂ (ເພີ່ມເຕີມກ່ຽວກັບວ່າຂ້າງລຸ່ມນີ້), ແລະອື່ນໆ. ໃຫ້ພວກເຮົາເບິ່ງການແກ້ໄຂກັບມັນ.

// Спрячем объект для Монитора от всех, чтобы без дедлоков.
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);
    }
}

ອີກເທື່ອໜຶ່ງພວກເຮົາປິດກັ້ນໂຕະທັງໝົດເພື່ອເຂົ້າຫາສ້ອມ, ແຕ່ຕອນນີ້ພວກເຮົາກຳລັງປົດບລັອກທຸກຫົວຂໍ້ໃນເທື່ອດຽວ, ແລະບໍ່ແມ່ນເພື່ອນບ້ານເມື່ອມີຄົນກິນເຂົ້າແລ້ວ. ເຫຼົ່ານັ້ນ. ທໍາອິດ, ມີຄົນກິນແລະຕັນປະເທດເພື່ອນບ້ານ, ແລະໃນເວລາທີ່ຄົນນີ້ສໍາເລັດ, ແຕ່ຕ້ອງການທີ່ຈະກິນອາຫານອີກເທື່ອຫນຶ່ງທັນທີ, ລາວເຂົ້າໄປໃນຕັນແລະປຸກເພື່ອນບ້ານຂອງຕົນ, ເພາະວ່າ. ເວລາລໍຖ້າຂອງມັນຫນ້ອຍລົງ.

ນີ້​ຄື​ວິທີ​ທີ່​ພວກ​ເຮົາ​ຫຼີກ​ລ່ຽງ​ການ​ປິດ​ລ້ອມ​ແລະ​ຄວາມ​ອຶດຢາກ​ຂອງ​ນັກ​ປັດຊະຍາ​ບາງ​ຄົນ. ພວກເຮົາໃຊ້ loop ສໍາລັບການລໍຖ້າສັ້ນແລະຕັນກະທູ້ສໍາລັບຍາວຫນຶ່ງ. ການປົດບລັອກທຸກຄົນໃນຄັ້ງດຽວແມ່ນຊ້າກວ່າຖ້າພຽງແຕ່ເພື່ອນບ້ານຖືກປົດບລັອກ, ຄືກັບການແກ້ໄຂດ້ວຍ AutoResetEvent, ແຕ່ຄວາມແຕກຕ່າງບໍ່ຄວນຈະມີຂະຫນາດໃຫຍ່, ເພາະວ່າ ກະທູ້ຕ້ອງຢູ່ໃນໂໝດຜູ້ໃຊ້ກ່ອນ.

У lock syntax ມີຄວາມແປກໃຈທີ່ຫນ້າປະຫລາດໃຈ. ແນະນໍາໃຫ້ໃຊ້ Monitor ໂດຍກົງ [Richter] [Eric Lippert]. ຫນຶ່ງໃນນັ້ນແມ່ນ lock ສະເຫມີອອກຈາກ Monitor, ເຖິງແມ່ນວ່າມີຂໍ້ຍົກເວັ້ນ, ໃນກໍລະນີນີ້ກະທູ້ອື່ນສາມາດປ່ຽນສະຖານະຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນໄດ້. ໃນກໍລະນີດັ່ງກ່າວ, ມັນມັກຈະດີກວ່າທີ່ຈະໄປ deadlock ຫຼື somehow ຢຸດໂຄງການຢ່າງປອດໄພ. ຄວາມແປກໃຈອີກອັນຫນຶ່ງແມ່ນວ່າ Monitor ໃຊ້ຕັນ synchronization (SyncBlock), ເຊິ່ງມີຢູ່ໃນວັດຖຸທັງຫມົດ. ດັ່ງນັ້ນ, ຖ້າເລືອກວັດຖຸທີ່ບໍ່ເຫມາະສົມ, ເຈົ້າສາມາດຖືກຢຸດໄດ້ຢ່າງງ່າຍດາຍ (ຕົວຢ່າງ, ຖ້າເຈົ້າລັອກໃສ່ສາຍທີ່ເຊື່ອມຕໍ່). ພວກເຮົາໃຊ້ວັດຖຸທີ່ເຊື່ອງໄວ້ສະເຫມີສໍາລັບການນີ້.

ຮູບແບບຕົວແປຂອງເງື່ອນໄຂຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດຄວາມຄາດຫວັງຂອງບາງເງື່ອນໄຂທີ່ສັບສົນຫຼາຍຂື້ນ. ໃນ .NET, ມັນບໍ່ຄົບຖ້ວນ, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ເພາະວ່າ ໃນທາງທິດສະດີ, ຄວນຈະມີຫຼາຍໆແຖວຢູ່ໃນຕົວແປຫຼາຍ (ເຊັ່ນດຽວກັບ Posix Threads), ແລະບໍ່ແມ່ນຢູ່ໃນຫນຶ່ງ lok. ຫຼັງຈາກນັ້ນ, ຫນຶ່ງສາມາດເຮັດໃຫ້ພວກເຂົາສໍາລັບ philosophers ທັງຫມົດ. ແຕ່ເຖິງແມ່ນວ່າໃນຮູບແບບນີ້, ມັນອະນຸຍາດໃຫ້ທ່ານຫຼຸດຜ່ອນລະຫັດ.

ນັກປັດຊະຍາຫຼາຍຄົນຫຼື async / await

ຕົກລົງ, ດຽວນີ້ພວກເຮົາສາມາດບລັອກກະທູ້ໄດ້ຢ່າງມີປະສິດທິພາບ. ແຕ່ຈະເປັນແນວໃດຖ້າພວກເຮົາມີນັກປັດຊະຍາຫຼາຍ? 100? 10000? ຕົວຢ່າງ, ພວກເຮົາໄດ້ຮັບການຮ້ອງຂໍ 100000 ກັບເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌. ມັນຈະເປັນ overhead ເພື່ອສ້າງ thread ສໍາລັບແຕ່ລະຄໍາຮ້ອງຂໍ, ເນື່ອງຈາກວ່າ ຫຼາຍກະທູ້ຈະບໍ່ດໍາເນີນການຂະຫນານ. ຈະດໍາເນີນການພຽງແຕ່ຫຼາຍເທົ່າທີ່ມີຫຼັກເຫດຜົນ (ຂ້າພະເຈົ້າມີ 4). ແລະຄົນອື່ນພຽງແຕ່ຈະເອົາຊັບພະຍາກອນໄປ. ຫນຶ່ງໃນການແກ້ໄຂບັນຫານີ້ແມ່ນຮູບແບບ async / ລໍຖ້າ. ຄວາມຄິດຂອງມັນແມ່ນວ່າຫນ້າທີ່ບໍ່ຖືກະທູ້ຖ້າມັນຕ້ອງການລໍຖ້າບາງສິ່ງບາງຢ່າງທີ່ຈະສືບຕໍ່. ແລະເມື່ອມັນເຮັດບາງສິ່ງບາງຢ່າງ, ມັນສືບຕໍ່ການປະຕິບັດ (ແຕ່ບໍ່ຈໍາເປັນຕ້ອງຢູ່ໃນກະທູ້ດຽວກັນ!). ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາຈະລໍຖ້າສໍາລັບສ້ອມ.

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 ໄດ້ຖືກແປເປັນເຄື່ອງຈັກຂອງລັດ tricky ທີ່ທັນທີກັບຄືນພາຍໃນຂອງຕົນ Task. ຜ່ານມັນ, ທ່ານສາມາດລໍຖ້າການສໍາເລັດຂອງວິທີການ, ຍົກເລີກມັນ, ແລະທຸກສິ່ງທຸກຢ່າງທີ່ທ່ານສາມາດເຮັດໄດ້ກັບ Task. ພາຍໃນວິທີການ, ເຄື່ອງຈັກຂອງລັດຄວບຄຸມການປະຕິບັດ. ເສັ້ນທາງລຸ່ມແມ່ນວ່າຖ້າບໍ່ມີການຊັກຊ້າ, ຫຼັງຈາກນັ້ນການປະຕິບັດແມ່ນ synchronous, ແລະຖ້າມີ, ຫຼັງຈາກນັ້ນກະທູ້ຖືກປ່ອຍອອກມາ. ສໍາລັບຄວາມເຂົ້າໃຈທີ່ດີກວ່ານີ້, ມັນກໍ່ດີກວ່າທີ່ຈະເບິ່ງເຄື່ອງຈັກຂອງລັດນີ້. ທ່ານສາມາດສ້າງຕ່ອງໂສ້ຈາກເຫຼົ່ານີ້ async / await ວິທີການ.

ໃຫ້ທົດສອບ. ການເຮັດວຽກຂອງນັກປັດຊະຍາ 100 ຄົນໃນເຄື່ອງຈັກທີ່ມີ 4 ຫຼັກເຫດຜົນ, 8 ວິນາທີ. ການແກ້ໄຂທີ່ຜ່ານມາກັບ Monitor ພຽງແຕ່ແລ່ນ 4 threads ທໍາອິດແລະສ່ວນທີ່ເຫຼືອບໍ່ໄດ້ດໍາເນີນການທັງຫມົດ. ແຕ່ລະກະທູ້ 4 ອັນນີ້ບໍ່ມີເວລາປະມານ 2ms. ແລະການແກ້ໄຂ async / awai ແລ່ນທັງຫມົດ 100, ດ້ວຍການລໍຖ້າໂດຍສະເລ່ຍ 6.8 ວິນາທີແຕ່ລະຄົນ. ແນ່ນອນ, ໃນລະບົບທີ່ແທ້ຈິງ, idle ສໍາລັບ 6 ວິນາທີແມ່ນບໍ່ສາມາດຍອມຮັບໄດ້ແລະມັນດີກວ່າທີ່ຈະບໍ່ດໍາເນີນການຮ້ອງຂໍຈໍານວນຫຼາຍເຊັ່ນນີ້. ການແກ້ໄຂກັບ Monitor ໄດ້ກາຍເປັນບໍ່ສາມາດຂະຫຍາຍໄດ້ທັງຫມົດ.

ສະຫລຸບ

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້ຈາກຕົວຢ່າງນ້ອຍໆເຫຼົ່ານີ້, .NET ສະຫນັບສະຫນູນໂຄງສ້າງ synchronization ຫຼາຍ. ຢ່າງໃດກໍຕາມ, ມັນບໍ່ແມ່ນສິ່ງທີ່ຈະແຈ້ງສະເຫມີວິທີການນໍາໃຊ້ພວກມັນ. ຂ້ອຍຫວັງວ່າບົດຄວາມນີ້ເປັນປະໂຫຍດ. ສໍາລັບໃນປັດຈຸບັນ, ນີ້ແມ່ນຈຸດຈົບ, ແຕ່ຍັງມີສິ່ງທີ່ຫນ້າສົນໃຈຫຼາຍທີ່ຍັງເຫຼືອ, ຕົວຢ່າງເຊັ່ນ: ການເກັບກະທູ້ທີ່ປອດໄພ, TPL Dataflow, ການຂຽນໂປຼແກຼມ Reactive, ຮູບແບບການເຮັດທຸລະກໍາຊອບແວ, ແລະອື່ນໆ.

ແຫຼ່ງຂໍ້ມູນ

• ການສະແດງພາບກະແສ: Concurrency Visualizer
• MSDN: ກະທູ້, ຮູບແບບການຂຽນໂປລແກລມ Asynchronous ແລະອື່ນໆ ດຣ.
• [Richter] - CLR ຜ່ານ C#, Jeffrey Richter
• [Eric Lippert] - ກ່ຽວກັບການລັອກ
• ລະຫັດແຫຼ່ງຂໍ້ມູນ
• ຮູບພາບ - "ເຕັ້ນລໍາລະຫວ່າງດາບ", G. Semiradsky

ແຫຼ່ງຂໍ້ມູນ: www.habr.com