Async vs. Threads: Debat Pemrograman yang Tak Kunjung Berakhir

Dalam dunia pengembangan perangkat lunak, hanya sedikit topik yang memicu diskusi berapi-api seperti pilihan antara pemrograman async/await dan threading tradisional. Sementara artikel teknis terbaru mengeksplorasi implikasi kinerja dari kedua pendekatan tersebut, komunitas pengembang secara aktif memperdebatkan pertanyaan arsitektural yang lebih mendalam tentang bagaimana kita menangani operasi konkuren dalam aplikasi modern.

Ketegangan Inti Antara Konkurensi Eksplisit dan Implisit

Pembagian mendasar dalam debat ini berpusat pada seberapa banyak kontrol yang seharusnya dimiliki pengembang atas operasi konkuren. Async/await membuat konkurensi menjadi eksplisit - setiap titik penangguhan ditandai dengan kata kunci await, menciptakan apa yang beberapa orang sebut sebagai fungsi berwarna yang berperilaku berbeda dari kode sinkron. Eksplisitas ini datang dengan beban kognitif tetapi memberi pengembang kontrol yang terperinci atas kapan operasi menghasilkan kontrol.

Implementasi green thread seperti yang ada pada goroutines Go atau bahasa BEAM (Erlang, Elixir) mengambil pendekatan sebaliknya. Mereka membuat konkurensi hampir tak terlihat pada tingkat kode, mengandalkan sistem runtime yang canggih untuk mengelola penjadwalan dan pergantian konteks. Seperti yang dicatat oleh seorang komentator tentang bahasa BEAM: Anda tidak memiliki keterikatan canggung antara kata kunci yang dipesan dan event loop. Jika Anda ingin bagian lain dari sesuatu terjadi nanti karena suatu peristiwa, Anda hanya mengatur agar peristiwa semacam itu dapat dikirimkan.

Tidak ada callback. Tidak ada pewarnaan async. Hanya peristiwa. Solusi untuk masalah peristiwa adalah berkomitmen penuh dan membuat event loop Anda lebih umum dapat digunakan.

Pertukaran Kinerja di Luar Tolok Ukur Sederhana

Sementara diskusi awal sering berfokus pada throughput mentah, debat komunitas mengungkap pertimbangan kinerja yang lebih bernuansa. Implementasi Async/await biasanya menggunakan state machine yang hanya menyimpan variabel yang diperlukan selama penangguhan, membuatnya efisien memori untuk workload yang terikat I/O. Green thread, bagaimanapun, mempertahankan stack penuh untuk setiap tugas konkuren, yang dapat lebih intensif memori tetapi menghindari perobekan stack yang diperlukan oleh state machine async.

Percakapan tentang kinerja telah berkembang untuk mengakui bahwa kedua pendekatan telah melampaui batasan asli mereka. .NET sedang mengembangkan Runtime Async untuk menggantikan state machine eksplisit dengan mekanisme penangguhan runtime, sementara Go telah meningkatkan manajemen stack-nya dari stack yang terbagi menjadi penyalinan stack. Seperti yang diamati oleh seorang pengembang, Baik green thread maupun async/await secara signifikan lebih mahal daripada kode single-threaded, tetapi biayanya terwujud dalam cara yang berbeda.

Perbedaan Utama Antara Async/Await dan Green Threads

Pembagian Ekosistem dan Peralatan

Mungkin pertimbangan paling praktis yang muncul dari diskusi komunitas adalah kematangan ekosistem di sekitar setiap pendekatan. Async/await telah menjadi ada di mana-mana di seluruh Python, JavaScript, C#, dan Rust, menciptakan banyak perpustakaan yang kompatibel dan pola yang mapan. Namun, ini datang dengan masalah pewarnaan fungsi di mana kode async dan sinkron sering tidak tercampur dengan mulus.

Ekosistem green thread, khususnya bahasa BEAM, menawarkan kemampuan komputasi terdistribusi yang pada dasarnya dibangun ke dalam desain mereka. Seperti yang dijelaskan oleh seorang komentator: BEAM dimaksudkan untuk komputasi terdistribusi. Anda dapat membuat proses baru, berkomunikasi antar proses (yang tidak harus berada di komputer yang sama), mengirimkan segala jenis data di antara mereka termasuk closure. Distribusi bawaan ini merupakan keuntungan arsitektural yang signifikan untuk kasus penggunaan tertentu.

Implementasi Notable berdasarkan Bahasa Pemrograman

• Async/Await: asyncio Python, async/await JavaScript, async C, async/await Rust
• Green Threads: goroutine Go, bahasa BEAM (proses Erlang/Elixir), Java Project Loom
• Pendekatan Hybrid: Runtime Async .NET yang akan datang, berbagai pilihan runtime Rust

Alat yang Tepat untuk Pekerjaan yang Tepat

Konsensus yang muncul dari diskusi pengembang menunjukkan bahwa pilihan antara paradigma ini sangat bergantung pada persyaratan aplikasi spesifik. Async/await unggul dalam lingkungan yang terbatas sumber daya dan pemrograman sistem, sementara green thread memberikan ergonomi pengembang yang superior untuk aplikasi bisnis dan sistem terdistribusi.

Banyak pengembang sekarang mengambil pendekatan hibrida, menggunakan runtime async single-threaded untuk operasi manajemen sambil menggunakan solusi multi-threaded untuk pekerjaan yang kritis terhadap kinerja. Seperti yang dibagikan oleh seorang praktisi: Dalam pekerjaan saya dengan kode sisi server, saya menggunakan beberapa runtime async. Satu runtime adalah multithreaded dan menangani semua lalu lintas nyata. Satu runtime adalah singlethreaded dan menangani operasi manajemen seperti mengirimkan metrik dan log.

Debat terus berkembang seiring dengan munculnya implementasi baru. Rust sekarang memiliki runtime async seperti Glommio dan Monoio yang dibangun di atas io_uring, sementara peningkatan .NET yang akan datang menjanjikan untuk mengurangi kesenjangan kinerja antara kode async dan sinkron. Yang jelas adalah bahwa kedua pendekatan akan terus hidup berdampingan, masing-masing memecahkan masalah yang berbeda dalam lanskap kompleks pengembangan perangkat lunak modern.

Percakapan seputar async versus thread tidak lagi tentang pendekatan mana yang secara universal lebih baik, tetapi lebih tentang memahami pertukaran dan memilih alat yang tepat untuk kasus penggunaan tertentu. Seiring bahasa pemrograman terus berkembang, kita melihat konvergensi daripada divergensi, dengan setiap ekosistem meminjam ide-ide sukses dari yang lain.

Referensi: [Quite] A Few Words About Async