ਵੈਲ-ਫੈਡ ਫਿਲਾਸਫਰ ਜਾਂ ਪ੍ਰਤੀਯੋਗੀ .NET ਪ੍ਰੋਗਰਾਮਿੰਗ

ਆਓ ਦੇਖੀਏ ਕਿ .Net ਵਿੱਚ ਸਮਕਾਲੀ ਅਤੇ ਸਮਾਨਾਂਤਰ ਪ੍ਰੋਗਰਾਮਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਫਿਲਾਸਫਰਸ ਡਾਇਨਿੰਗ ਸਮੱਸਿਆ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ। ਯੋਜਨਾ ਇਹ ਹੈ, ਥਰਿੱਡਾਂ / ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸਮਕਾਲੀਕਰਨ ਤੋਂ, ਅਭਿਨੇਤਾ ਮਾਡਲ ਤੱਕ (ਹੇਠਲੇ ਭਾਗਾਂ ਵਿੱਚ)। ਲੇਖ ਪਹਿਲੇ ਜਾਣੂ ਲਈ ਜਾਂ ਤੁਹਾਡੇ ਗਿਆਨ ਨੂੰ ਤਾਜ਼ਾ ਕਰਨ ਲਈ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ।

ਇਹ ਸਭ ਕਿਉਂ ਕਰਦੇ ਹਨ? ਟਰਾਂਜ਼ਿਸਟਰ ਆਪਣੇ ਘੱਟੋ-ਘੱਟ ਆਕਾਰ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ, ਮੂਰ ਦਾ ਨਿਯਮ ਪ੍ਰਕਾਸ਼ ਦੀ ਗਤੀ ਦੀ ਸੀਮਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਲਈ ਗਿਣਤੀ ਵਿੱਚ ਵਾਧਾ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਹੋਰ ਟਰਾਂਜ਼ਿਸਟਰ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਉਸੇ ਸਮੇਂ, ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਵਧ ਰਹੀ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਸਿਸਟਮਾਂ ਤੋਂ ਤੁਰੰਤ ਜਵਾਬ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ. ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ, "ਆਮ" ਪ੍ਰੋਗਰਾਮਿੰਗ, ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਇੱਕ ਐਗਜ਼ੀਕਿਊਟਿੰਗ ਥਰਿੱਡ ਹੁੰਦਾ ਹੈ, ਹੁਣ ਪ੍ਰਭਾਵੀ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਹਾਨੂੰ ਸਮਕਾਲੀ ਜਾਂ ਸਮਕਾਲੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਸਮੱਸਿਆ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ 'ਤੇ ਮੌਜੂਦ ਹੈ: ਥਰਿੱਡਾਂ ਦੇ ਪੱਧਰ 'ਤੇ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਪੱਧਰ' ਤੇ, ਨੈਟਵਰਕ (ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ) ਵਿੱਚ ਮਸ਼ੀਨਾਂ ਦੇ ਪੱਧਰ 'ਤੇ. .NET ਕੋਲ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਅਤੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਹੱਲ ਕਰਨ ਲਈ ਉੱਚ-ਗੁਣਵੱਤਾ, ਸਮਾਂ-ਪਰੀਖਣ ਵਾਲੀਆਂ ਤਕਨਾਲੋਜੀਆਂ ਹਨ।

ਉਦੇਸ਼

ਐਡਸਗਰ ਡਿਜਕਸਟ੍ਰਾ ਨੇ 1965 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਆਪਣੇ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਇਹ ਸਮੱਸਿਆ ਪੇਸ਼ ਕੀਤੀ ਸੀ। ਸਥਾਪਿਤ ਫਾਰਮੂਲੇ ਇਸ ਤਰ੍ਹਾਂ ਹੈ। ਦਾਰਸ਼ਨਿਕਾਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ (ਆਮ ਤੌਰ 'ਤੇ ਪੰਜ) ਗਿਣਤੀ ਹੈ ਅਤੇ ਕਾਂਟੇ ਦੀ ਇੱਕੋ ਜਿਹੀ ਗਿਣਤੀ ਹੈ। ਉਹ ਇੱਕ ਗੋਲ ਮੇਜ਼ 'ਤੇ ਬੈਠਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਦੇ ਵਿਚਕਾਰ ਕਾਂਟੇ ਹੁੰਦੇ ਹਨ. ਫਿਲਾਸਫਰ ਬੇਅੰਤ ਭੋਜਨ ਦੀਆਂ ਪਲੇਟਾਂ ਵਿੱਚੋਂ ਖਾ ਸਕਦੇ ਹਨ, ਸੋਚ ਸਕਦੇ ਹਨ ਜਾਂ ਉਡੀਕ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਦਾਰਸ਼ਨਿਕ ਨੂੰ ਖਾਣ ਲਈ, ਤੁਹਾਨੂੰ ਦੋ ਕਾਂਟੇ ਲੈਣ ਦੀ ਲੋੜ ਹੈ (ਆਖਰੀ ਇੱਕ ਕਾਂਟੇ ਨੂੰ ਪਹਿਲੇ ਨਾਲ ਸਾਂਝਾ ਕਰਦਾ ਹੈ)। ਫੋਰਕ ਨੂੰ ਚੁੱਕਣਾ ਅਤੇ ਹੇਠਾਂ ਰੱਖਣਾ ਦੋ ਵੱਖਰੀਆਂ ਕਾਰਵਾਈਆਂ ਹਨ। ਸਾਰੇ ਦਾਰਸ਼ਨਿਕ ਚੁੱਪ ਹਨ। ਕੰਮ ਅਜਿਹਾ ਐਲਗੋਰਿਥਮ ਲੱਭਣ ਦਾ ਹੈ ਕਿ ਸਾਰੇ 54 ਸਾਲਾਂ ਬਾਅਦ ਵੀ ਸੋਚਣਗੇ ਅਤੇ ਪੂਰੇ ਹੋਣਗੇ।

ਪਹਿਲਾਂ, ਆਓ ਸਾਂਝੀ ਥਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ। ਕਾਂਟੇ ਸਾਂਝੇ ਮੇਜ਼ 'ਤੇ ਪਏ ਹੁੰਦੇ ਹਨ ਅਤੇ ਦਾਰਸ਼ਨਿਕ ਉਨ੍ਹਾਂ ਨੂੰ ਉਦੋਂ ਲੈਂਦੇ ਹਨ ਜਦੋਂ ਉਹ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵਾਪਸ ਪਾ ਦਿੰਦੇ ਹਨ। ਇੱਥੇ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕਦੋਂ ਲੈਣਾ ਹੈ? ਜੇ ਕੋਈ ਕਾਂਟਾ ਨਹੀਂ ਹੈ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? ਆਦਿ ਪਰ ਪਹਿਲਾਂ, ਆਓ ਦਾਰਸ਼ਨਿਕਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰੀਏ।

ਥਰਿੱਡ ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਥਰਿੱਡ ਪੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ Task.Run ਵਿਧੀ:

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

ਥਰਿੱਡ ਪੂਲ ਨੂੰ ਥਰਿੱਡ ਬਣਾਉਣ ਅਤੇ ਮਿਟਾਉਣ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਪੂਲ ਵਿੱਚ ਕਾਰਜਾਂ ਦੇ ਨਾਲ ਇੱਕ ਕਤਾਰ ਹੈ ਅਤੇ CLR ਇਹਨਾਂ ਕਾਰਜਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਅਧਾਰ 'ਤੇ ਥਰਿੱਡ ਬਣਾਉਂਦਾ ਜਾਂ ਹਟਾਉਂਦਾ ਹੈ। ਸਾਰੇ 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।

ਚਿੱਤਰ ਵਿੱਚ, ਬਲਾਕਿੰਗ ਥਰਿੱਡ (ਡੈੱਡਲਾਕ)। ਗ੍ਰੀਨ - ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਲਾਲ - ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ, ਸਲੇਟੀ - ਥਰਿੱਡ ਸੁੱਤਾ ਹੋਇਆ ਹੈ. ਰੋਮਬਸ ਟਾਸਕ ਦੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ।

ਫਿਲਾਸਫਰਾਂ ਦੀ ਭੁੱਖ

ਹਾਲਾਂਕਿ ਖਾਸ ਤੌਰ 'ਤੇ ਬਹੁਤਾ ਭੋਜਨ ਸੋਚਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ, ਪਰ ਭੁੱਖ ਕਿਸੇ ਨੂੰ ਵੀ ਫਲਸਫੇ ਨੂੰ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਆਉ ਸਾਡੀ ਸਮੱਸਿਆ ਵਿੱਚ ਥਰਿੱਡਾਂ ਦੀ ਭੁੱਖਮਰੀ ਦੀ ਸਥਿਤੀ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ. ਭੁੱਖਮਰੀ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੱਕ ਧਾਗਾ ਚੱਲ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਮਹੱਤਵਪੂਰਨ ਕੰਮ ਦੇ ਬਿਨਾਂ, ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਹ ਉਹੀ ਡੈੱਡਲਾਕ ਹੈ, ਸਿਰਫ ਹੁਣ ਧਾਗਾ ਸੁੱਤਾ ਨਹੀਂ ਹੈ, ਪਰ ਸਰਗਰਮੀ ਨਾਲ ਖਾਣ ਲਈ ਕੁਝ ਲੱਭ ਰਿਹਾ ਹੈ, ਪਰ ਕੋਈ ਭੋਜਨ ਨਹੀਂ ਹੈ. ਵਾਰ-ਵਾਰ ਬਲਾਕਿੰਗ ਤੋਂ ਬਚਣ ਲਈ, ਜੇਕਰ ਅਸੀਂ ਕੋਈ ਹੋਰ ਨਹੀਂ ਲੈ ਸਕਦੇ ਤਾਂ ਅਸੀਂ ਫੋਰਕ ਨੂੰ ਵਾਪਸ ਰੱਖ ਦਿਆਂਗੇ।

// То же что и в 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 (ਮਿਊਟੈਕਸ) ਹੈ, ਪਰ ਲੂਪ, ਰੀਕਰਸ਼ਨ, ਕੰਡੀਸ਼ਨ ਵੇਰੀਏਬਲ ਪੈਟਰਨ (ਹੇਠਾਂ ਇਸ ਬਾਰੇ ਹੋਰ), ਆਦਿ ਵਿੱਚ ਉਡੀਕ ਕਰਨ ਲਈ ਸਮਰਥਨ ਦੇ ਨਾਲ। ਆਉ ਇਸਦੇ ਨਾਲ ਇੱਕ ਹੱਲ ਵੇਖੀਏ।

// Спрячем объект для Монитора от всех, чтобы без дедлоков.
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), ਜੋ ਸਾਰੀਆਂ ਵਸਤੂਆਂ ਵਿੱਚ ਮੌਜੂਦ ਹਨ। ਇਸ ਲਈ, ਜੇਕਰ ਕੋਈ ਅਣਉਚਿਤ ਵਸਤੂ ਚੁਣੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਇੱਕ ਡੈੱਡਲਾਕ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਅੰਦਰੂਨੀ ਸਤਰ 'ਤੇ ਲਾਕ ਕਰ ਸਕਦੇ ਹੋ)। ਅਸੀਂ ਇਸਦੇ ਲਈ ਹਮੇਸ਼ਾ ਲੁਕੀ ਹੋਈ ਵਸਤੂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਕੰਡੀਸ਼ਨ ਵੇਰੀਏਬਲ ਪੈਟਰਨ ਤੁਹਾਨੂੰ ਕੁਝ ਗੁੰਝਲਦਾਰ ਸਥਿਤੀ ਦੀ ਉਮੀਦ ਨੂੰ ਹੋਰ ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। .NET ਵਿੱਚ, ਇਹ ਅਧੂਰਾ ਹੈ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਕਿਉਂਕਿ ਥਿਊਰੀ ਵਿੱਚ, ਕਈ ਵੇਰੀਏਬਲਾਂ ਉੱਤੇ ਕਈ ਕਤਾਰਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਕਿ ਪੋਸਿਕਸ ਥ੍ਰੈਡਸ ਵਿੱਚ), ਨਾ ਕਿ ਇੱਕ ਲੋਕ ਉੱਤੇ। ਫਿਰ ਕੋਈ ਉਹਨਾਂ ਨੂੰ ਸਾਰੇ ਦਾਰਸ਼ਨਿਕਾਂ ਲਈ ਬਣਾ ਸਕਦਾ ਹੈ। ਪਰ ਇਸ ਫਾਰਮ ਵਿੱਚ ਵੀ, ਇਹ ਤੁਹਾਨੂੰ ਕੋਡ ਨੂੰ ਘਟਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ.

ਬਹੁਤ ਸਾਰੇ ਦਾਰਸ਼ਨਿਕ ਜ async / await

ਠੀਕ ਹੈ, ਹੁਣ ਅਸੀਂ ਥਰਿੱਡਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਬਲੌਕ ਕਰ ਸਕਦੇ ਹਾਂ। ਪਰ ਉਦੋਂ ਕੀ ਜੇ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਦਾਰਸ਼ਨਿਕ ਹਨ? 100? 10000? ਉਦਾਹਰਨ ਲਈ, ਸਾਨੂੰ ਵੈੱਬ ਸਰਵਰ ਨੂੰ 100000 ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਹੋਈਆਂ ਹਨ। ਹਰੇਕ ਬੇਨਤੀ ਲਈ ਇੱਕ ਥਰਿੱਡ ਬਣਾਉਣਾ ਓਵਰਹੈੱਡ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਇੰਨੇ ਸਾਰੇ ਥ੍ਰੈੱਡ ਸਮਾਨਾਂਤਰ ਨਹੀਂ ਚੱਲਣਗੇ। ਸਿਰਫ ਓਨੇ ਹੀ ਚੱਲਣਗੇ ਜਿੰਨੇ ਲਾਜ਼ੀਕਲ ਕੋਰ ਹਨ (ਮੇਰੇ ਕੋਲ 4 ਹਨ)। ਅਤੇ ਬਾਕੀ ਹਰ ਕੋਈ ਵਸੀਲੇ ਖੋਹ ਲਵੇਗਾ। ਇਸ ਸਮੱਸਿਆ ਦਾ ਇੱਕ ਹੱਲ async/await ਪੈਟਰਨ ਹੈ। ਇਸਦਾ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਫੰਕਸ਼ਨ ਥਰਿੱਡ ਨੂੰ ਨਹੀਂ ਰੱਖਦਾ ਹੈ ਜੇਕਰ ਇਸਨੂੰ ਜਾਰੀ ਰੱਖਣ ਲਈ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ. ਅਤੇ ਜਦੋਂ ਇਹ ਕੁਝ ਕਰਦਾ ਹੈ, ਇਹ ਇਸਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ (ਪਰ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਉਸੇ ਧਾਗੇ 'ਤੇ!) ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ ਫੋਰਕ ਦੀ ਉਡੀਕ ਕਰਾਂਗੇ.

SemaphoreSlim ਇਸ ਲਈ ਹੈ WaitAsync() ਢੰਗ. ਇੱਥੇ ਇਸ ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਲਾਗੂਕਰਨ ਹੈ।

// Запуск такой же, как раньше. Где-нибудь в программе:
Task.Run(() => Run(i, cancelTokenSource.Token));

// Запуск философа.
// Ключевое слово async -- компилятор транслирует этот метот в асинхронный.
public async Task Run(int i, CancellationToken token)
{
    while (true)
    {
        // await -- будем ожидать какого-то события.
        await TakeForks(i);
        // После await, продолжение возможно в другом потоке.
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        // Может быть несколько событий для ожидания.
        await PutForks(i);

        Think(i);

        if (token.IsCancellationRequested) break;
    }
}

async Task TakeForks(int i)
{
    bool hasForks = false;
    while (!hasForks)
    {
        // Взаимоисключающий доступ к столу:
        await _tableSemaphore.WaitAsync();
        if (forks[Left(i)] == 0 && forks[Right(i)] == 0)
        {
            forks[Left(i)] = i+1;
            forks[Right(i)] = i+1;
            hasForks = true;
        }
        _tableSemaphore.Release();
        // Будем ожидать, чтобы сосед положил вилки:
        if (!hasForks)
            await _philosopherSemaphores[i].WaitAsync();
    }
}

// Ждем доступа к столу и кладем вилки.
async Task PutForks(int i)
{
    await _tableSemaphore.WaitAsync();
    forks[Left(i)] = 0;
    // "Пробудить" соседей, если они "спали".
    _philosopherSemaphores[LeftPhilosopher(i)].Release();
    forks[Right(i)] = 0;
    _philosopherSemaphores[RightPhilosopher(i)].Release();
    _tableSemaphore.Release();
}

ਨਾਲ ਵਿਧੀ async / await ਇੱਕ ਛਲ ਸਟੇਟ ਮਸ਼ੀਨ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਤੁਰੰਤ ਇਸਦੇ ਅੰਦਰੂਨੀ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ Task. ਇਸਦੇ ਦੁਆਰਾ, ਤੁਸੀਂ ਵਿਧੀ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਸਕਦੇ ਹੋ, ਇਸਨੂੰ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ ਜੋ ਤੁਸੀਂ ਟਾਸਕ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ। ਵਿਧੀ ਦੇ ਅੰਦਰ, ਰਾਜ ਮਸ਼ੀਨ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ. ਤਲ ਲਾਈਨ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਕੋਈ ਦੇਰੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਕਾਲੀ ਹੈ, ਅਤੇ ਜੇਕਰ ਹੈ, ਤਾਂ ਥਰਿੱਡ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਇਸ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਣ ਲਈ, ਇਸ ਰਾਜ ਮਸ਼ੀਨ ਨੂੰ ਵੇਖਣਾ ਬਿਹਤਰ ਹੈ. ਤੁਸੀਂ ਇਹਨਾਂ ਤੋਂ ਚੇਨ ਬਣਾ ਸਕਦੇ ਹੋ async / await ਢੰਗ.

ਆਓ ਟੈਸਟ ਕਰੀਏ। 100 ਲਾਜ਼ੀਕਲ ਕੋਰ, 4 ਸਕਿੰਟਾਂ ਵਾਲੀ ਮਸ਼ੀਨ 'ਤੇ 8 ਫਿਲਾਸਫਰਾਂ ਦਾ ਕੰਮ। ਮਾਨੀਟਰ ਦੇ ਨਾਲ ਪਿਛਲਾ ਹੱਲ ਸਿਰਫ ਪਹਿਲੇ 4 ਥਰਿੱਡਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਸੀ ਅਤੇ ਬਾਕੀ ਬਿਲਕੁਲ ਨਹੀਂ ਚੱਲਦਾ ਸੀ। ਇਹਨਾਂ 4 ਥਰਿੱਡਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਲਗਭਗ 2ms ਲਈ ਵਿਹਲਾ ਸੀ। ਅਤੇ async/await ਦਾ ਹੱਲ 100 ਸਕਿੰਟਾਂ ਦੀ ਔਸਤ ਉਡੀਕ ਦੇ ਨਾਲ, ਸਾਰੇ 6.8 ਚੱਲਿਆ। ਬੇਸ਼ੱਕ, ਅਸਲ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ, 6 ਸਕਿੰਟਾਂ ਲਈ ਨਿਸ਼ਕਿਰਿਆ ਅਸਵੀਕਾਰਨਯੋਗ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਨਾ ਕਰਨਾ ਬਿਹਤਰ ਹੈ। ਮਾਨੀਟਰ ਵਾਲਾ ਹੱਲ ਬਿਲਕੁਲ ਵੀ ਸਕੇਲੇਬਲ ਨਹੀਂ ਨਿਕਲਿਆ।

ਸਿੱਟਾ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਇਹਨਾਂ ਛੋਟੀਆਂ ਉਦਾਹਰਣਾਂ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ, .NET ਬਹੁਤ ਸਾਰੀਆਂ ਸਮਕਾਲੀ ਉਸਾਰੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਹਮੇਸ਼ਾ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਹ ਲੇਖ ਮਦਦਗਾਰ ਸੀ. ਹੁਣ ਲਈ, ਇਹ ਅੰਤ ਹੈ, ਪਰ ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਬਾਕੀ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਥਰਿੱਡ-ਸੁਰੱਖਿਅਤ ਸੰਗ੍ਰਹਿ, TPL ਡੇਟਾਫਲੋ, ਰਿਐਕਟਿਵ ਪ੍ਰੋਗਰਾਮਿੰਗ, ਸੌਫਟਵੇਅਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਮਾਡਲ, ਆਦਿ।

ਸਰੋਤ

• ਪ੍ਰਵਾਹ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ: ਸਮਰੂਪਤਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ਰ
• MSDN: ਥ੍ਰੈਡਿੰਗ, ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰੋਗਰਾਮਿੰਗ ਪੈਟਰਨ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਡਾ.
• [ਰਿਕਟਰ] - C# ਦੁਆਰਾ CLR, ਜੈਫਰੀ ਰਿਕਟਰ
• [ਏਰਿਕ ਲਿਪਰਟ] - ਲਾਕ ਬਾਰੇ
• ਸਰੋਤ ਕੋਡ
• ਤਸਵੀਰ - "ਤਲਵਾਰਾਂ ਵਿਚਕਾਰ ਨੱਚੋ", ਜੀ. ਸੇਮੀਰਾਡਸਕੀ

ਸਰੋਤ: www.habr.com