Pemrograman asinkron lebih merupakan filosofi daripada sekadar trik pemrograman lainnya. Sementara, pertanyaan terakhir Anda menarik jawaban terutama tentang aspek pemrograman dan jawaban saya adalah penyendiri terputus karena sebagian besar teoritis, saya mencoba untuk memberi Anda membangun perspektif baru pada baris yang sama tetapi penjelasan daripada sekadar referensi.
Yang ini adalah tentang beberapa dasar mengapa dan bagaimana Pemrograman Asinkron.
Misalkan Anda pergi ke toko roti (dan dengan asumsi kue akan disiapkan setelah pesanan) - Anda memiliki dua pilihan, baik Anda memilih menunggu sampai kue siap atau Anda memberikan pesanan dan kembali ke rumah dan mengambil nanti kalau sudah siap. Yang pertama (tunggu) adalah metode sinkron dan kemudian metode asinkron . Tak perlu dikatakan contoh ini memberikan referensi yang baik mengapa Anda harus menggunakan metode asinkronik dari sinkron.
Pemrograman berbasis acara hanya salah satu cara sistem asinkron dapat dibangun dan itu bukan hanya pola desain yang berguna tetapi lebih merupakan pola arsitektur. Saya mencatat kasus-kasus di mana teori ini digunakan dengan cara yang praktis berguna - berharap itu akan membawa kejelasan
Salah satu contoh pertama dari sistem Asynchronous adalah sistem Unix IO. Meskipun kita tahu read(), write()dan bahkan select()panggilan memblokir aliran program, tetapi di dalam OS, mereka asinkron, yaitu kernel umumnya tahu bahwa perangkat blok (alias hard disk) akan membutuhkan waktu untuk mengisi buffer, sampai saat itu CPU bebas dari utas masing-masing dan karenanya utas diparkir sebagai (tidak siap). Lihat 1. Moris Bach "Desain sistem operasi Unix"
Contoh paling umum lainnya adalah mayoritas kerangka kerja UI. Di sini, semua klik pengguna dikirim pertama kali melalui pengontrol yang pada gilirannya akan memanggil kembali aplikasi yang bersangkutan. Yang penting adalah panggilan balik seperti itu tidak boleh membuat panggilan balik menunggu lagi karena sistem akan membeku. Panggilan kembali dari pengontrol UI ke back-end biasanya tidak sinkron jika melibatkan pemrosesan yang berat.
Contoh bagus lain dari pemrograman asinkron (sebagai pola desain murni) adalah Objek Aktif. Objek aktif adalah objek yang memiliki utas pribadi sendiri sehingga seseorang dapat menyimpan banyak permintaan dalam antrian dan mengeksekusi satu per satu. Lihat Makalah ini: Objek Aktif . Pola ini banyak digunakan langsung dari perangkat lunak Enterprise hingga kerangka kerja seluler. Platform Java / EJB dan .NET yang populer memungkinkan pemanggilan metode Asynchronous Lokal atau Jauh yang pada dasarnya memungkinkan objek normal menjadi objek aktif. Objek aktif hadir jauh di Symbian: Objek aktif di Symbian OS oleh Aapo Haapanen (lihat ini juga: Objek Aktif di Symbian ). Ini sekarang juga hadir diAndroid ).
Terlepas dari objek Aktif, penulis yang sama Douglas C. Schmidt , telah menghasilkan sejumlah karya lain yang sejajar dengan objek Aktif dan juga pola asinkron. Lihat Pola Penanganan Acara ini dan akun lengkap tersedia di bukunya Arsitektur Pola Berorientasi Perangkat Lunak: Pola untuk Objek Bersamaan dan Jaringan - V2
Ketika objek tertentu perlu mengembalikan API, saat bekerja di latar belakang untuk benar-benar menyelesaikan pekerjaan, metodologi yang biasa adalah memiliki sistem multi-threaded untuk mencapai ini. Sistem berulir ada di mana-mana dari C (posix), C ++ ( boost ) ke Java, C # dan seterusnya. Objek Aktif pada dasarnya hanya abstraksi yang dapat menyembunyikan ini. Lihat mengapa implementasi objek aktif lebih disukai daripada utas telanjang. Bacaan lain yang bagus .
Tetapi konsep ini melampaui benang atau objek di dalam aplikasi menjadi asinkron. Salah satu penggunaan yang terbaik adalah dalam sistem terdistribusi di mana dua aplikasi tidak selalu perlu menunggu satu sama lain untuk co-pentahbisan. Baik tua (atau tidak begitu baik, dengan cara apa pun Anda melihatnya) RPC sinkron. [tentu saja, ada juga RPC asinkron lainnya ]. Tetapi alternatif modern seperti Message Oriented Middleware benar-benar tidak sinkron untuk alasan yang baik.
Terakhir tetapi bisa menjadi yang paling menarik, adalah pemrograman Agen yang dapat mengambil manfaat dari model komunikasi Asynchronous .
Meskipun pemrograman asinkron memang terlihat seksi tetapi menciptakan kompleksitasnya sendiri termasuk:
- kerangka kerja untuk kelulusan nilai pengembalian
- overhead komunikasi tambahan
- kebutuhan tambahan untuk sinkronisasi konstruksi
- kemungkinan kebuntuan, balap dll jika hal-hal tidak dilakukan dengan benar.
... dan seterusnya.
Itu harus selalu digunakan hanya untuk alasan yang tulus.
Jadi kapan harus menggunakan model Asynchronous? Kapan sebaiknya Anda menempatkan thread latar belakang dan memungkinkan penelpon untuk pergi asynchronous? Berikut adalah beberapa aturan yang baik praktis ketika itu berlaku (tapi tidak lengkap)
Ketika sistem ingin menerapkan percakapan sumber daya serius yang ketat: misalnya, Anda ingin tetap memiliki jumlah utas yang tetap. Pola asinkron memaksa sistem untuk mengimplementasikan antrian.
Ketika kebutuhan penelepon untuk melakukan "hal-hal lain yang berguna untuk dilakukan" memang asli. Berkali-kali, utas lainnya bahkan jika diblokir, tidak akan melakukan apa pun yang berguna dan bergantung pada hasil polling. Ini memang bisa lebih memakan CPU daripada model sinkron dasar.
Ketika Anda membutuhkan tingkat keandalan yang lebih tinggi dalam sistem terdistribusi. (lihat Middleware Berorientasi Pesan ).