Filsuf yang Kaya atau Pemrograman .NET yang Kompetitif

Mari kita lihat bagaimana pemrograman bersamaan dan paralel bekerja di .Net, menggunakan Masalah Makan Bertuah sebagai contoh. Rencananya begini, dari sinkronisasi utas/proses, hingga model aktor (di bagian berikut). Artikel tersebut mungkin berguna untuk kenalan pertama atau untuk menyegarkan pengetahuan Anda.

Mengapa melakukannya sama sekali? Transistor mencapai ukuran minimumnya, hukum Moore bertumpu pada batasan kecepatan cahaya dan oleh karena itu terlihat peningkatan jumlah, lebih banyak transistor dapat dibuat. Pada saat yang sama, jumlah data bertambah, dan pengguna mengharapkan tanggapan langsung dari sistem. Dalam situasi seperti itu, pemrograman "normal", saat kita memiliki satu utas yang mengeksekusi, tidak lagi efektif. Anda perlu entah bagaimana memecahkan masalah eksekusi simultan atau bersamaan. Selain itu, masalah ini ada di level yang berbeda: di level utas, di level proses, di level mesin di jaringan (sistem terdistribusi). .NET memiliki teknologi berkualitas tinggi yang telah teruji waktu untuk memecahkan masalah tersebut dengan cepat dan efisien.

Tugas

Edsger Dijkstra mengajukan masalah ini kepada murid-muridnya sejak tahun 1965. Rumusan yang ditetapkan adalah sebagai berikut. Ada sejumlah (biasanya lima) filsuf dan jumlah garpu yang sama. Mereka duduk di meja bundar, bercabang di antara mereka. Filsuf dapat makan dari piring makanan mereka yang tak ada habisnya, berpikir atau menunggu. Untuk memakan seorang filsuf, Anda perlu mengambil dua garpu (yang terakhir berbagi garpu dengan yang pertama). Mengambil dan meletakkan garpu adalah dua tindakan terpisah. Semua filsuf diam. Tugasnya adalah menemukan algoritme sedemikian rupa sehingga semuanya akan berpikir dan menjadi penuh bahkan setelah 54 tahun.

Pertama, mari kita coba selesaikan masalah ini melalui penggunaan ruang bersama. Garpu terletak di atas meja bersama dan para filsuf hanya mengambilnya ketika sudah ada dan meletakkannya kembali. Di sini ada masalah dengan sinkronisasi, kapan tepatnya mengambil surebet? bagaimana jika tidak ada garpu? dll. Tapi pertama-tama, mari kita mulai para filsuf.

Untuk memulai utas, kami menggunakan kumpulan utas melalui Task.Run metode:

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);
}

Kumpulan utas dirancang untuk mengoptimalkan pembuatan dan penghapusan utas. Kumpulan ini memiliki antrean dengan tugas dan CLR membuat atau menghapus utas tergantung pada jumlah tugas ini. Satu kumpulan untuk semua AppDomains. Kolam ini harus digunakan hampir selalu, karena. tidak perlu repot membuat, menghapus utas, antreannya, dll. Dimungkinkan tanpa kumpulan, tetapi Anda harus menggunakannya secara langsung Thread, ini berguna untuk kasus-kasus ketika Anda perlu mengubah prioritas utas, ketika kami memiliki operasi yang panjang, untuk utas Foreground, dll.

Dengan kata lain, System.Threading.Tasks.Task kelasnya sama Thread, tetapi dengan segala kemudahan: kemampuan untuk menjalankan tugas setelah blok tugas lain, mengembalikannya dari fungsi, menginterupsi dengan mudah, dan banyak lagi. dll. Mereka diperlukan untuk mendukung konstruksi async / menunggu (Pola Asinkron Berbasis Tugas, gula sintaksis untuk menunggu operasi IO). Kita akan membicarakan ini nanti.

CancelationTokenSource di sini diperlukan agar utas dapat mengakhiri dirinya sendiri atas sinyal utas pemanggil.

Masalah Sinkronisasi

Filsuf yang Diblokir

Oke kita sudah tahu cara membuat thread, mari kita coba makan siang :

// Кто какие вилки взял. К примеру: 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();
    }
}

Di sini pertama-tama kita coba ambil garpu kiri, lalu garpu kanan, dan jika berhasil, baru kita makan dan taruh kembali. Mengambil satu garpu adalah atom, mis. dua utas tidak dapat mengambil satu pada saat yang sama (salah: yang pertama berbunyi bahwa garpu itu gratis, yang kedua - juga, yang pertama diambil, yang kedua diambil). Untuk ini Interlocked.CompareExchange, yang harus diimplementasikan dengan instruksi prosesor (TSL, XCHG), yang mengunci sepotong memori untuk membaca dan menulis sekuensial atom. Dan SpinWait setara dengan konstruksinya while(true) hanya dengan sedikit "sihir" - utas mengambil prosesor (Thread.SpinWait), tetapi terkadang mentransfer kontrol ke utas lain (Thread.Yeild) atau tertidur (Thread.Sleep).

Tetapi solusi ini tidak berhasil, karena aliran segera (untuk saya dalam satu detik) diblokir: semua filsuf mengambil garpu kiri mereka, tetapi bukan yang kanan. Forks array kemudian memiliki nilai: 1 2 3 4 5.

Pada gambar, memblokir utas (kebuntuan). Hijau - eksekusi, merah - sinkronisasi, abu-abu - utas sedang tidur. Belah ketupat menunjukkan waktu mulai Tugas.

Kelaparan Para Filsuf

Meski tidak perlu memikirkan makanan apalagi banyak, namun rasa lapar membuat siapapun menyerah pada filosofi. Mari kita coba simulasikan situasi kelaparan utas dalam masalah kita. Kelaparan adalah saat utas berjalan, tetapi tanpa kerja yang berarti, dengan kata lain, ini adalah jalan buntu yang sama, hanya sekarang utas tidak tidur, tetapi aktif mencari sesuatu untuk dimakan, tetapi tidak ada makanan. Untuk menghindari pemblokiran yang sering, kami akan mengembalikan garpu jika kami tidak dapat mengambil yang lain.

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

Hal penting tentang kode ini adalah bahwa dua dari empat filsuf lupa meletakkan garpu kirinya. Dan ternyata mereka makan lebih banyak, sementara yang lain mulai kelaparan, meski utasnya memiliki prioritas yang sama. Di sini mereka tidak sepenuhnya kelaparan, karena. filsuf yang buruk kadang-kadang mengembalikan garpu mereka. Ternyata orang baik makan sekitar 5 kali lebih sedikit daripada orang jahat. Jadi kesalahan kecil dalam kode menyebabkan penurunan kinerja. Perlu juga dicatat di sini bahwa situasi yang jarang terjadi ketika semua filsuf mengambil garpu kiri, tidak ada garpu kanan, mereka meletakkan kiri, menunggu, mengambil kiri lagi, dll. Situasi ini juga merupakan kelaparan, lebih seperti kebuntuan. Saya gagal mengulanginya. Di bawah ini adalah gambaran situasi di mana dua filsuf jahat telah mengambil kedua garpu dan dua filsuf baik kelaparan.

Di sini Anda dapat melihat bahwa utas kadang-kadang bangun dan mencoba mendapatkan sumber daya. Dua dari empat inti tidak melakukan apa-apa (grafik hijau di atas).

Kematian Seorang Filsuf

Nah, masalah lain yang bisa mengganggu jamuan makan malam para filsuf adalah jika salah satu dari mereka tiba-tiba mati dengan garpu di tangannya (dan mereka akan menguburnya seperti itu). Maka tetangga akan dibiarkan tanpa makan siang. Anda dapat membuat sendiri contoh kode untuk kasus ini, misalnya, dibuang NullReferenceException setelah filsuf mengambil garpu. Dan, omong-omong, pengecualian tidak akan ditangani dan kode panggilan tidak akan menangkapnya begitu saja (untuk ini AppDomain.CurrentDomain.UnhandledException dan sebagainya.). Oleh karena itu, penangan kesalahan diperlukan di utas itu sendiri dan dengan penghentian yang baik.

Pelayan

Oke, bagaimana kita mengatasi masalah kebuntuan, kelaparan, dan kematian ini? Kami hanya akan mengizinkan satu filsuf untuk mencapai percabangan, menambahkan pengecualian utas bersama untuk tempat ini. Bagaimana cara melakukannya? Misalkan seorang pelayan berdiri di samping para filsuf, yang memberikan izin kepada salah satu filsuf untuk mengambil garpu. Bagaimana kita membuat pelayan ini dan bagaimana para filsuf akan menanyakannya, pertanyaannya menarik.

Cara paling sederhana adalah ketika para filsuf terus-menerus meminta akses ke garpu kepada pelayan. Itu. sekarang para filsuf tidak akan menunggu garpu di dekatnya, tetapi menunggu atau bertanya kepada pelayan. Pada awalnya, kami hanya menggunakan Ruang Pengguna untuk ini, di dalamnya kami tidak menggunakan interupsi untuk memanggil prosedur apa pun dari kernel (tentangnya di bawah).

Solusi di ruang pengguna

Di sini kita akan melakukan hal yang sama seperti yang biasa kita lakukan dengan satu garpu dan dua filsuf, kita akan berputar dalam satu siklus dan menunggu. Tetapi sekarang semuanya akan menjadi filsuf dan, seolah-olah, hanya satu garpu, yaitu. dapat dikatakan bahwa hanya filsuf yang mengambil "garpu emas" ini dari pelayan yang akan makan. Untuk ini kami menggunakan 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 ini adalah pemblokir, dengan, secara kasar, sama while(true) { if (!lock) break; }, tetapi dengan lebih banyak "sihir" daripada di SpinWait (yang digunakan di sana). Sekarang dia tahu bagaimana menghitung mereka yang menunggu, menidurkan mereka sedikit, dan banyak lagi. dll. Secara umum, apakah segala kemungkinan untuk dioptimalkan. Tetapi kita harus ingat bahwa ini masih merupakan siklus aktif yang sama yang memakan sumber daya prosesor dan menjaga arus, yang dapat menyebabkan kelaparan jika salah satu filsuf menjadi lebih diprioritaskan daripada yang lain, tetapi tidak memiliki garpu emas (masalah Pembalikan Prioritas) . Oleh karena itu, kami menggunakannya hanya untuk perubahan yang sangat singkat dalam memori bersama, tanpa panggilan pihak ketiga, kunci bersarang, dan kejutan lainnya.

Menggambar untuk SpinLock. Aliran terus-menerus "berjuang" untuk garpu emas. Ada kegagalan - pada gambar, area yang dipilih. Inti tidak digunakan sepenuhnya: hanya sekitar 2/3 dari keempat utas ini.

Solusi lain di sini adalah dengan menggunakan saja Interlocked.CompareExchange dengan menunggu aktif yang sama seperti yang ditunjukkan pada kode di atas (pada filsuf yang kelaparan), tetapi ini, seperti yang telah dikatakan, secara teoritis dapat menyebabkan pemblokiran.

Tentang Interlocked Perlu dicatat bahwa tidak hanya ada CompareExchange, tetapi juga metode lain untuk pembacaan dan penulisan atomik. Dan melalui pengulangan perubahan, jika utas lain memiliki waktu untuk melakukan perubahannya (baca 1, baca 2, tulis 2, tulis 1 buruk), itu dapat digunakan untuk perubahan kompleks pada satu nilai (pola Apa Pun yang Berinterlock).

Solusi Mode Kernel

Untuk menghindari pemborosan sumber daya dalam satu lingkaran, mari kita lihat bagaimana kita dapat memblokir sebuah utas. Dengan kata lain, melanjutkan contoh kita, mari kita lihat bagaimana pelayan menidurkan filsuf dan membangunkannya hanya jika diperlukan. Pertama, mari kita lihat bagaimana melakukannya melalui mode kernel sistem operasi. Semua struktur di sana seringkali lebih lambat daripada yang ada di ruang pengguna. Beberapa kali lebih lambat, misalnya AutoResetEvent mungkin 53 kali lebih lambat SpinLock [Richter]. Tetapi dengan bantuan mereka, Anda dapat menyinkronkan proses di seluruh sistem, dikelola atau tidak.

Konstruksi dasar di sini adalah semaphore yang diusulkan oleh Dijkstra lebih dari setengah abad yang lalu. Sederhananya, semafor adalah bilangan bulat positif yang dikelola oleh sistem, dan dua operasi di atasnya, kenaikan dan penurunan. Jika gagal berkurang, nol, maka utas panggilan diblokir. Ketika nomor bertambah oleh beberapa utas/proses aktif lainnya, maka utas dilewati dan semafor kembali dikurangi dengan nomor yang diteruskan. Orang bisa membayangkan kereta di kemacetan dengan semaphore. .NET menawarkan beberapa konstruksi dengan fungsionalitas serupa: AutoResetEvent, ManualResetEvent, Mutex dan diriku sendiri Semaphore. Kami akan menggunakan AutoResetEvent, ini adalah konstruksi yang paling sederhana: hanya dua nilai 0 dan 1 (salah, benar). Metodenya WaitOne() memblokir utas panggilan jika nilainya 0, dan jika 1, turunkan ke 0 dan lewati. Sebuah metode Set() naik ke 1 dan membiarkan satu pelayan lewat, yang turun lagi ke 0. Bertindak seperti pintu putar kereta bawah tanah.

Mari kita perumit solusinya dan gunakan kunci untuk setiap filsuf, dan bukan untuk semuanya sekaligus. Itu. sekarang bisa ada beberapa filsuf sekaligus, dan bukan satu. Tapi kami kembali memblokir akses ke meja agar benar, menghindari balapan (kondisi balapan), ambil surebet.

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

Untuk memahami apa yang terjadi di sini, perhatikan kasus ketika filsuf gagal mengambil garpu, maka tindakannya adalah sebagai berikut. Dia sedang menunggu akses ke meja. Setelah menerimanya, dia mencoba mengambil garpu. Tidak berhasil. Ini memberikan akses ke tabel (pengecualian bersama). Dan melewati "pintu putar" nya (AutoResetEvent) (mereka awalnya terbuka). Itu masuk ke siklus lagi, karena dia tidak punya garpu. Dia mencoba mengambilnya dan berhenti di "pintu putar" -nya. Beberapa tetangga yang lebih beruntung di kanan atau kiri, setelah selesai makan, membuka kunci filsuf kita, "membuka pintu putar". Filsuf kita melewatinya (dan menutup di belakangnya) untuk kedua kalinya. Dia mencoba untuk ketiga kalinya mengambil garpu. Semoga beruntung. Dan dia melewati pintu putar untuk makan.

Ketika ada kesalahan acak dalam kode tersebut (selalu ada), misalnya, tetangga salah ditentukan atau objek yang sama dibuat AutoResetEvent untuk semua (Enumerable.Repeat), maka para filsuf akan menunggu para pengembangnya, karena Menemukan kesalahan dalam kode semacam itu adalah tugas yang cukup sulit. Masalah lain dengan solusi ini adalah tidak menjamin bahwa beberapa filsuf tidak akan kelaparan.

Solusi hibrid

Kami telah melihat dua pendekatan untuk pengaturan waktu, saat kami tetap dalam mode pengguna dan loop, dan saat kami memblokir utas melalui kernel. Metode pertama bagus untuk kunci pendek, yang kedua untuk kunci panjang. Seringkali perlu menunggu sebentar untuk variabel berubah dalam satu lingkaran, dan kemudian memblokir utas saat menunggu lama. Pendekatan ini diimplementasikan dalam apa yang disebut. struktur hibrida. Berikut adalah konstruksi yang sama untuk mode kernel, tetapi sekarang dengan loop mode pengguna: SemaphorSlim, ManualResetEventSlim dll. Desain paling populer di sini adalah Monitor, Karena di C # ada yang terkenal lock sintaksis. Monitor ini adalah semafor yang sama dengan nilai maksimum 1 (mutex), tetapi dengan dukungan untuk menunggu dalam satu lingkaran, rekursi, pola Variabel Kondisi (lebih lanjut di bawah), dll. Mari kita lihat solusinya.

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

Di sini kami sekali lagi memblokir seluruh tabel untuk akses ke garpu, tetapi sekarang kami membuka blokir semua utas sekaligus, dan bukan tetangga saat seseorang selesai makan. Itu. pertama, seseorang makan dan memblokir tetangganya, dan ketika seseorang selesai, tetapi ingin makan lagi segera, dia memblokir dan membangunkan tetangganya, karena. waktu tunggunya kurang.

Beginilah cara kami menghindari kebuntuan dan kelaparan beberapa filsuf. Kami menggunakan loop untuk menunggu sebentar dan memblokir utas untuk waktu yang lama. Membuka blokir semua orang sekaligus lebih lambat daripada jika hanya tetangga yang dibuka blokirnya, seperti dalam solusi dengan AutoResetEvent, tetapi perbedaannya tidak boleh besar, karena utas harus tetap dalam mode pengguna terlebih dahulu.

У lock sintaks memiliki kejutan yang tidak menyenangkan. Merekomendasikan untuk digunakan Monitor langsung [Richter] [Eric Lippert]. Salah satunya adalah itu lock selalu keluar dari Monitor, bahkan jika ada pengecualian, dalam hal ini utas lain dapat mengubah status memori bersama. Dalam kasus seperti itu, seringkali lebih baik pergi ke kebuntuan atau entah bagaimana menghentikan program dengan aman. Kejutan lainnya adalah Monitor menggunakan blok sinkronisasi (SyncBlock), yang ada di semua objek. Oleh karena itu, jika objek yang tidak sesuai dipilih, Anda dapat dengan mudah mengalami kebuntuan (misalnya, jika Anda mengunci string yang diinternir). Kami menggunakan objek selalu tersembunyi untuk ini.

Pola Variabel Kondisi memungkinkan Anda untuk mengimplementasikan ekspektasi dari beberapa kondisi kompleks secara lebih ringkas. Di .NET kurang lengkap menurut saya karena secara teori, harus ada beberapa antrian pada beberapa variabel (seperti pada Posix Threads), dan bukan pada satu lok. Kemudian seseorang dapat membuatnya untuk semua filsuf. Tetapi bahkan dalam bentuk ini memungkinkan Anda untuk mengurangi kode.

banyak filsuf atau async / await

Oke, sekarang kita bisa memblokir utas secara efektif. Tetapi bagaimana jika kita memiliki banyak filsuf? 100? 10000? Misalnya, kami menerima 100000 permintaan ke server web. Ini akan menjadi overhead untuk membuat utas untuk setiap permintaan, karena begitu banyak utas tidak akan berjalan secara paralel. Hanya akan berjalan sebanyak inti logis (saya punya 4). Dan semua orang hanya akan mengambil sumber daya. Salah satu solusi untuk masalah ini adalah pola async / await. Idenya adalah bahwa fungsi tersebut tidak menahan utas jika perlu menunggu sesuatu untuk dilanjutkan. Dan ketika ia melakukan sesuatu, ia melanjutkan eksekusinya (tetapi tidak harus di utas yang sama!). Dalam kasus kami, kami akan menunggu garpu.

SemaphoreSlim memiliki untuk ini WaitAsync() metode. Berikut adalah implementasi menggunakan pola ini.

// Запуск такой же, как раньше. Где-нибудь в программе:
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();
}

Metode dengan async / await diterjemahkan ke dalam mesin keadaan rumit yang segera mengembalikan internalnya Task. Melalui itu, Anda dapat menunggu penyelesaian metode, membatalkannya, dan semua hal lain yang dapat Anda lakukan dengan Task. Di dalam metode, mesin negara mengontrol eksekusi. Intinya adalah jika tidak ada penundaan, maka eksekusi akan sinkron, dan jika ada, maka utas dilepaskan. Untuk pemahaman yang lebih baik tentang ini, lebih baik melihat mesin negara ini. Anda dapat membuat rantai dari ini async / await metode.

Mari kita uji. Karya 100 filsuf pada mesin dengan 4 inti logis, 8 detik. Solusi sebelumnya dengan Monitor hanya menjalankan 4 utas pertama dan sisanya tidak berjalan sama sekali. Masing-masing dari 4 utas ini menganggur selama sekitar 2 md. Dan solusi async / await berjalan 100, dengan rata-rata menunggu masing-masing 6.8 detik. Tentu saja, dalam sistem nyata, menganggur selama 6 detik tidak dapat diterima dan lebih baik tidak memproses begitu banyak permintaan seperti ini. Solusi dengan Monitor ternyata tidak dapat diskalakan sama sekali.

Kesimpulan

Seperti yang Anda lihat dari contoh kecil ini, .NET mendukung banyak konstruksi sinkronisasi. Namun, tidak selalu jelas bagaimana menggunakannya. Semoga artikel ini bermanfaat. Untuk saat ini, ini adalah akhir, tetapi masih banyak hal menarik yang tersisa, misalnya koleksi thread-safe, TPL Dataflow, Pemrograman reaktif, model Transaksi Perangkat Lunak, dll.

sumber

• Visualisasi aliran: Visualizer Konkurensi
• MSDN: threading, Pola pemrograman asinkron dan banyak lainnya lainnya
• [Richter] - CLR melalui C#, Jeffrey Richter
• [Eric Lippert] - Tentang kunci
• Sumber
• Gambar - "Menari di antara pedang", G. Semiradsky

Sumber: www.habr.com