Pencarian yang Sulit untuk Penghentian Thread Linux yang Bersih

Dalam dunia pemrograman sistem Linux yang kompleks, para pengembang menghadapi tantangan terus-menerus yang tampak sederhana: bagaimana cara menghentikan thread yang sedang berjalan dengan bersih. Meskipun memulai thread itu mudah, memastikan mereka berhenti dengan anggun tanpa menyebabkan kebocoran sumber daya atau merusak data telah memicu perdebatan luas di kalangan insinyur. Diskusi komunitas mengungkapkan lanskap yang dipenuhi pertukaran teknis, di mana tidak ada solusi tunggal yang cocok untuk semua skenario.

Masalah Mendasar dengan Penghentian Paksa

Masalah inti dengan menghentikan thread secara tiba-tiba terletak pada manajemen sumber daya. Ketika sebuah thread dihentikan di tengah eksekusi, thread tersebut mungkin sedang memegang kunci, telah mengalokasikan memori yang perlu dibebaskan, atau berada di tengah operasi kritis. Seorang komentator dengan sempurna menggambarkan bahayanya: Ya, dan biarkan mutex terkunci tanpa batas waktu. Skenario ini dapat menyebabkan kebuntuan (deadlock), kebocoran memori, atau struktur data yang rusak yang memengaruhi seluruh aplikasi. Masalah ini menjadi sangat akut ketika berhadapan dengan pustaka pihak ketiga atau kode yang tidak dirancang dengan mempertimbangkan penghentian yang bersih.

Pendekatan Berbasis Sinyal dan Keterbatasannya

Banyak pengembang awalnya beralih ke sinyal sebagai solusi untuk menginterupsi thread yang diblokir. Ide ini sederhana: kirim sinyal untuk membangunkan thread dari panggilan sistem yang memblokir, lalu perintahkan untuk memeriksa bendera penghentian. Namun, pendekatan ini menderita kondisi balapan antara memeriksa bendera dan memasuki panggilan sistem. Bahkan ketika menggunakan varian yang aman dari sinyal seperti pselect dan ppoll, solusinya tidak lengkap. Seperti yang dicatat oleh seorang insinyur, Pendekatan yang benar adalah menghindari panggilan sistem sederhana seperti sleep() atau recv(), dan sebagai gantinya menggunakan panggilan multipleks seperti epoll() atau io_uring(). Ini memungkinkan menunggu beberapa peristiwa secara bersamaan, termasuk sinyal penghentian.

Kontroversi Pembatalan pthread

POSIX thread menyediakan mekanisme pembatalan yang pada awalnya tampak menjanjikan. Namun, komunitas pengembang sebagian besar telah menolak pendekatan ini karena implikasi berbahayanya. Mekanisme ini bekerja dengan membuka gulungan stack ketika permintaan pembatalan diterima, tetapi ini dapat terjadi hampir di titik mana pun dalam eksekusi. Hal ini menjadi sangat bermasalah dalam C++ modern di mana destruktor secara default adalah noexcept, yang berarti pembatalan selama penghancuran akan segera mengakhiri program. Seorang komentator menjelaskan realitas yang bernuansa: Ini memiliki dua mode: asinkron dan tertunda. Dalam mode asinkron, sebuah thread dapat dibatalkan kapan saja, bahkan di tengah bagian kritis dengan kunci yang dipegang.

Saya teringat banyak blog Raymond Chen tentang mengapa TerminateThread adalah ide yang buruk. Tidak heran hal yang sama juga berlaku di tempat lain.

Istilah Teknis Utama:

• Operasi atomik: Operasi yang selesai tanpa gangguan, sangat penting untuk pemeriksaan flag yang aman antar thread
• Memory barrier: Instruksi CPU yang menerapkan batasan urutan pada operasi memori
• Signal mask: Sekumpulan sinyal yang saat ini diblokir dari pengiriman ke sebuah thread
• Cancellation point: Fungsi-fungsi spesifik di mana pembatalan thread dapat terjadi dengan aman dalam mode tertunda
• Condition variable: Primitif sinkronisasi yang memungkinkan thread menunggu kondisi tertentu
• Eventfd: Sebuah file descriptor Linux yang dirancang khusus untuk notifikasi event antar thread

Pendekatan Kooperatif Muncul sebagai Solusi yang Disukai

Konsensus di antara pengembang yang berpengalaman sangat condong ke arah penghentian kooperatif. Ini melibatkan penstrukturan kode thread untuk secara berkala memeriksa bendera penghentian selama titik putus alami dalam eksekusi. Banyak yang menyarankan penggunaan loop peristiwa dengan mekanisme seperti variabel kondisi atau eventfd yang dapat secara bersamaan menunggu item pekerjaan dan sinyal penghentian. Pendekatan ini menghindari bahaya interupsi asinkron sambil memberikan responsivitas yang wajar. Seperti yang diringkas oleh seorang komentator: Saya tidak akan pernah merekomendasikan untuk mengandalkan sinyal dan menulis handler pembersihan khusus untuk mereka. Kecuali mereka diblokir menunggu peristiwa eksternal, sebagian besar panggilan sistem cenderung kembali dalam waktu yang wajar.

Perbandingan Metode Penghentian Thread yang Umum:

Arsitektur Alternatif dan Solusi Lainnya

Saat berhadapan dengan operasi pemblokiran yang benar-benar bermasalah, beberapa pengembang merekomendasikan perubahan arsitektur yang lebih radikal. Salah satu pendekatan melibatkan mengisolasi kode yang tidak dapat diandalkan dalam proses terpisah daripada thread, memungkinkan sistem operasi membersihkan sumber daya ketika proses diakhiri. Yang lain menyarankan penggunaan batas waktu (timeout) pada panggilan sistem atau menugaskan operasi pemblokiran ke kumpulan thread khusus yang dapat ditinggalkan dengan aman. Pengenalan baru-baru ini tentang rseq (restartable sequences) di Linux 5.11 menawarkan solusi teknis lain, meskipun membutuhkan pemrograman assembly dan belum diadopsi secara luas.

Diskusi yang sedang berlangsung mengungkapkan bahwa penghentian thread yang bersih tetap menjadi masalah yang belum terpecahkan dalam kasus umum. Meskipun pendekatan kooperatif bekerja dengan baik untuk kode baru, menangani basis kode yang sudah ada atau pustaka pihak ketiga terus menantang para pengembang. Pengalaman kolektif komunitas menunjukkan bahwa perencanaan arsitektur yang hati-hati dari awal, menggunakan primitif sinkronisasi yang tepat dan loop peristiwa, memberikan jalan yang paling andal untuk penghentian yang bersih. Seiring sistem menjadi lebih kompleks, tantangan pemrograman mendasar ini terus menginspirasi solusi teknis dan pertimbangan ulang arsitektur.

Referensi: How to stop Linux threads cleanly