Sebuah artikel terbaru yang mempertanyakan efektivitas lockless queue telah memicu perdebatan sengit di komunitas pemrograman, dengan para developer mempertanyakan baik klaim performa maupun asumsi desain fundamental yang dikemukakan oleh penulis.
Artikel asli tersebut berargumen bahwa sebagian besar implementasi lockless queue secara fundamental cacat dan lambat, serta mengusulkan struktur data bag alternatif yang sama sekali meninggalkan jaminan pengurutan. Namun, pernyataan ini mendapat penolakan signifikan dari developer berpengalaman yang menunjukkan data performa dunia nyata yang bertentangan dengan klaim tersebut.
Angka Performa Menceritakan Kisah yang Berbeda
Anggota komunitas dengan cepat menantang pernyataan bahwa lockless queue lambat dengan data benchmarking yang konkret. Developer yang bekerja dengan ekosistem lockless queue Rust melaporkan bahwa implementasi tercepat dapat memproses lebih dari 30 juta elemen per detik, yang setara dengan hanya 33 nanodetik per elemen. Bahkan implementasi yang lebih lambat mencatat waktu sekitar 100 nanodetik per elemen, yang dianggap banyak orang cukup cepat untuk operasi concurrent.
Perdebatan semakin memanas ketika penulis asli membela posisi mereka dengan mengutip benchmark mereka sendiri yang menunjukkan waktu pemrosesan rata-rata 250 nanodetik dengan kontention berat. Kritikus berargumen bahwa ini mewakili implementasi spesifik dalam kondisi ekstrem daripada tuduhan umum terhadap teknologi lockless queue.
Perbandingan Performa Lockless Queue
- Implementasi tercepat: 30+ juta elemen/detik (33ns per elemen)
- Implementasi lebih lambat: 5-10 juta elemen/detik (100ns per elemen)
- Benchmark penulis dengan kontesi berat: ~4 juta elemen/detik (250ns per elemen)
Kontroversi Definisi Queue
Sebagian besar diskusi berpusat pada apa yang sebenarnya merupakan queue dalam lingkungan multi-threaded. Artikel asli mengklaim bahwa multi-consumer queue merusak pengurutan global dan karena itu bukan queue sejati. Anggota komunitas sangat tidak setuju dengan definisi sempit ini, menunjukkan bahwa queue dunia nyata jarang mempertahankan urutan pemrosesan global yang ketat.
Seorang developer menggunakan analogi balai kota dengan beberapa loket layanan untuk mengilustrasikan poin tersebut. Meskipun orang menerima tiket secara berurutan, mereka mungkin dilayani oleh loket yang berbeda dengan kecepatan berbeda, berpotensi menyelesaikan layanan di luar urutan asli. Ini mencerminkan bagaimana multi-consumer queue bekerja dalam praktik dan melayani kasus penggunaan yang sah.
Tantangan Implementasi dan Trade-off
Alternatif bag yang diusulkan mendapat skeptisisme dari developer yang familiar dengan struktur data concurrent. Kritikus mencatat bahwa implementasi bag masih memerlukan operasi atomik pada bitmask, yang dapat menciptakan bottleneck kontention mereka sendiri. Tantangan fundamental tetap ada: struktur data bersama apa pun yang diakses oleh beberapa thread harus mengkoordinasikan akses entah bagaimana.
Beberapa komentator menyoroti bahwa varian queue yang berbeda melayani tujuan yang berbeda. Queue MPSC (multiple-producer, single-consumer) banyak digunakan dalam task scheduler, sementara queue SPSC (single-producer, single-consumer) bekerja dengan baik untuk pipeline pemrosesan kustom. Pilihan tergantung pada persyaratan kasus penggunaan spesifik daripada karakteristik performa universal.
Yang tercepat dengan mudah melakukan setidaknya 30 juta elemen/detik dalam sebagian besar konfigurasi. Yang terlambat sekitar 5-10. Jadi yang tercepat melakukan 33ns per elemen dan yang terlambat adalah 100ns.
Jenis Queue dan Kasus Penggunaan
- SPSC (Single-Producer Single-Consumer): Pipeline pemrosesan khusus
- MPSC (Multiple-Producer Single-Consumer): Penjadwal tugas ( tokio , rayon )
- SPMC (Single-Producer Multiple-Consumer): Kasus penggunaan terbatas
- MPMC (Multiple-Producer Multiple-Consumer): Penjadwalan tugas umum
Implikasi Praktis untuk Developer
Perdebatan ini mengungkap pertimbangan penting bagi developer yang memilih struktur data concurrent. Meskipun artikel asli mengangkat poin valid tentang jaminan pengurutan, respons komunitas menekankan bahwa banyak aplikasi tidak memerlukan pengurutan global yang ketat. Fitur seperti fairness, penghindaran starvation, dan perilaku yang dapat diprediksi seringkali lebih penting daripada konsistensi sekuensial yang sempurna.
Diskusi ini juga menyoroti bahaya membuat klaim performa yang luas tanpa benchmarking komprehensif di berbagai skenario dan implementasi. Apa yang berkinerja baik dalam satu set kondisi mungkin kesulitan dalam kondisi lain, membuat konteks menjadi krusial untuk keputusan desain.
Kontroversi ini pada akhirnya menggarisbawahi kompleksitas pemrograman concurrent dan pentingnya memahami baik properti teoretis maupun karakteristik performa praktis dari pendekatan yang berbeda sebelum membuat keputusan arsitektural.
Referensi: Your MPSC/SPMC/MPMC queue is not a queue