Bug pada lock reader/writer di Windows API

Kemungkinan bug pada std::shared_mutex di Windows

• Sebuah tim perangkat lunak menemukan perilaku tak terduga yang terkait dengan std::shared_mutex di Windows.
• Masalah ini hanya terjadi di MSVC, dan tidak muncul di MinGW atau platform lain.
• Ketika thread utama memperoleh lock eksklusif lalu beberapa thread anak mencoba memperoleh lock bersama, "deadlock" terjadi kira-kira 1 dari 1000 kali.
• Saat deadlock terjadi, tepat 1 thread anak saja yang berhasil memperoleh lock bersama, sementara thread anak lainnya terblokir selamanya di lock_shared().
• Masalah ini diamati saat menggunakan std::shared_mutex, std::shared_lock/std::unique_lock, maupun saat memanggil fungsi SRW secara langsung.

Contoh kode dan reproduksi bug

• Disediakan kode sederhana yang dapat mereproduksi masalah ini.
• Kode tersebut mengulangi proses di mana thread utama memperoleh lock eksklusif, lalu beberapa thread anak memperoleh lock bersama dan kemudian melepaskannya.
• Kode ini menunjukkan bug terkait std::shared_mutex hanya pada implementasi Windows MSVC.

Pendapat para ahli

• Pengembang STL menyebut bahwa masalah ini tampak seperti bug pada Windows API.
• Ada diskusi mengenai langkah yang tepat untuk melaporkan bug ini, dan pengembang STL melaporkannya secara internal.
• Pengguna lain meneliti masalah ini lebih rinci dan berkontribusi mempersempit dugaan ke bug spesifik pada implementasi SRWLock.

Opini GN⁺

• Artikel ini memberikan informasi yang sangat penting khususnya bagi pengembang C++, karena potensi bug pada std::shared_mutex dapat memengaruhi mekanisme sinkronisasi pada aplikasi multithreading.
• Jika bug ini terkonfirmasi, hal itu dapat memengaruhi tingkat kepercayaan terhadap implementasi pustaka standar C++. Pengembang perlu menyadari masalah seperti ini dan mungkin perlu mempertimbangkan mekanisme sinkronisasi alternatif.
• Masalah ini bisa menjadi sangat penting terutama pada sistem berkinerja tinggi atau sistem real-time, karena deadlock dapat menimbulkan konsekuensi yang fatal.
• Sebelum mengadopsi teknologi ini, pengembang perlu melakukan pengujian ekstensif pada platform dan compiler terkait untuk memastikan tidak ada bug semacam ini.
• Untuk mengatasi masalah seperti ini, pengembang dapat mempertimbangkan pustaka sinkronisasi alternatif seperti Boost. Karena Boost telah diuji secara luas dan digunakan di banyak platform, pustaka ini dapat menjadi alternatif yang stabil untuk masalah semacam ini.

[GN⁺]

Opini Hacker News

• Seorang pengguna penasaran mengapa masalah yang mendasar ini tidak terdeteksi dalam waktu yang lama, sambil menyebut jawaban meyakinkan yang diberikan pengguna lain. Ia menunjukkan bahwa ada kasus ketika thread yang mencoba mengunci dalam mode bersama bisa secara keliru memperoleh kunci dalam mode eksklusif. Ini terjadi karena tumpang tindih operasi atomik pengujian bit dan penetapan saat thread pengambil mode bersama dan thread pelepas mode eksklusif berjalan secara bersamaan.

  • Seorang pengguna menjelaskan bahwa ada kode reproduksi di mana semua thread lain menunggu untuk memperoleh kunci bersama saat satu thread sedang memperoleh kunci bersama, sehingga jika suatu thread pekerja secara keliru mendapatkan kunci eksklusif, deadlock bisa terjadi. Dalam kasus penggunaan umum, thread tidak saling menunggu sehingga deadlock tidak terjadi.

• Pengguna lain menyebut bahwa ia tidak terkejut dengan bug halus yang muncul pada kunci Reader/Writer, dan membagikan pengalamannya mengerjakan implementasi internal berbasis Win32 sebelum C++11 dan std::shared_mutex. Ia mengatakan berusaha menghindari kunci bersama kecuali benar-benar diperlukan karena pengalaman buruk dengannya.

  • Seorang pengguna membagikan pengalaman negatifnya dengan kunci bersama, dengan menyebut bahwa performa std::shared_mutex jauh lebih buruk dibanding std::mutex sehingga melakukan double buffering pada data justru lebih cepat.

• Seorang pengguna menunjukkan bahwa judulnya menyesatkan, dan menjelaskan bahwa bug sebenarnya ada pada kunci slim reader/writer (SRW) di Windows API, dan ditemukan karena std::shared_mutex diimplementasikan menggunakan kunci SRW. Seorang karyawan Microsoft mengonfirmasi bahwa bug tersebut telah diajukan secara internal ke tim Windows API.

  • Seorang pengguna menyoroti judul yang menyesatkan dan menyebut bahwa masalah sebenarnya ada pada kunci SRW di Windows API, serta bahwa seorang karyawan Microsoft telah mengonfirmasi bug tersebut sudah diajukan.

• Seorang pengguna penasaran apakah masalah yang sama juga terjadi pada implementasi WINE, dan menyebut ingin mengujinya juga pada instalasi XP kustom miliknya. Ia mengatakan telah menambahkan berbagai ekstensi termasuk API SRW ke instalasi itu, dan menambal kernel untuk memperbaiki race condition yang menyebabkan deadlock pada API keyed event yang dibangun di atas implementasi SRW.

  • Seorang pengguna penasaran apakah masalah yang sama juga muncul pada implementasi WINE, dan menyebut ingin mengujinya di instalasi XP kustom miliknya. Pada instalasi ini, ia menambahkan berbagai ekstensi termasuk API SRW dan menambal kernel untuk memperbaiki race condition yang menyebabkan deadlock pada API keyed event berbasis implementasi SRW.

• Ditunjukkan bahwa program tersebut memiliki bug. Program itu mencampurkan variabel non-atomic dan atomic untuk digunakan dalam loop pemeriksaan yield(), dan variabel non-atomic tidak menjamin koherensi cache terhadap thread lain. Akibatnya, loop tersebut bisa berjalan selamanya.

  • Seorang pengguna menunjukkan bug pada program dan menjelaskan masalah yang timbul karena mencampurkan variabel non-atomic dan atomic. Variabel non-atomic tidak menjamin koherensi cache sehingga loop bisa berjalan tanpa akhir.

• Seorang pengguna menyebut bahwa bug ini berakar setidaknya sampai versi Vista tahun 2008, dan mengungkapkan keterkejutannya bahwa tidak seorang pun menemukan bug ini selama waktu selama itu. Ia menyebut bahwa pada penggunaan rwlock yang umum, kasus acak gagal memperoleh kunci bersama bisa terjadi, tetapi deadlock tidak terjadi.

  • Seorang pengguna menyebut bahwa bug ini sudah ada sejak versi Vista, dan merasa heran karena tidak terdeteksi selama bertahun-tahun. Ia juga menyebut bahwa pada penggunaan rwlock biasa, deadlock tidak terjadi tetapi ada kasus kegagalan memperoleh kunci bersama.

• Seorang pengguna menyebut bahwa melaporkan bug pada Windows API sangat sulit, dan mengkritik arahan untuk melaporkannya lewat Feedback Hub karena hampir tidak efektif. Pengguna tersebut melaporkan bug bahwa SRWLOCK bisa mengalami deadlock saat beberapa thread pembaca mencoba memperoleh kepemilikan bersama setelah pemilik eksklusif melepaskan kepemilikannya.

  • Seorang pengguna menyebut bahwa pelaporan bug pada Windows API sangat sulit dan mengkritik pelaporan melalui Feedback Hub sebagai tidak efektif. Ia juga membagikan bahwa dirinya pernah melaporkan bug terkait SRWLOCK.

• Seorang pengguna mengenang bahwa dulu saat membeli produk MS, seseorang bisa mendapatkan support incident, dan jika menemukan bug nyata maka support incident itu akan dikembalikan. Ia menyebut ini sebagai sistem yang baik karena bermanfaat bagi pengembang sekaligus memberi MS umpan balik untuk menemukan masalah nyata dan memperbaiki dokumentasi. Ia penasaran apakah program ini masih ada.

  • Seorang pengguna mengenang support incident yang dulu disertakan dalam produk MS, dan menyebut sistem itu menguntungkan baik bagi pengembang maupun MS. Ia penasaran apakah program tersebut masih ada saat ini.

• Terakhir, seorang pengguna mengungkapkan kekecewaan terhadap sulitnya melaporkan bug pada Windows API.

  • Seorang pengguna menyatakan kekecewaannya terhadap sulitnya pelaporan bug pada Windows API.