વેલ-ફેડ ફિલોસોફર્સ અથવા સ્પર્ધાત્મક .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: થ્રેડીંગ, અસુમેળ પ્રોગ્રામિંગ પેટર્ન અને ઘણા અન્ય અન્ય
• [રિક્ટર] - CLR વાયા C#, જેફરી રિક્ટર
• [એરિક લિપર્ટ] - લોક વિશે
• સ્રોત
• ચિત્ર - "તલવારો વચ્ચે નૃત્ય", જી. સેમિરાડસ્કી

સોર્સ: www.habr.com