Mengapa pthread_cond_wait memiliki wakeups palsu?

Mengutip halaman manual:

Saat menggunakan variabel kondisi selalu ada predikat Boolean yang melibatkan variabel bersama yang terkait dengan setiap kondisi, tunggu itu benar jika utas harus dilanjutkan. Wakeups palsu dari fungsi pthread_cond_timedwait () atau pthread_cond_wait () dapat terjadi. Karena pengembalian dari pthread_cond_timedwait () atau pthread_cond_wait () tidak menyiratkan apa-apa tentang nilai predikat ini, predikat harus dievaluasi kembali setelah pengembalian tersebut.

Jadi, pthread_cond_waitdapat kembali bahkan jika Anda belum mengisinya. Setidaknya pada pandangan pertama, itu tampak sangat mengerikan. Ini akan seperti fungsi yang secara acak mengembalikan nilai yang salah atau secara acak dikembalikan sebelum benar-benar mencapai pernyataan pengembalian yang tepat. Sepertinya bug utama. Tetapi fakta bahwa mereka memilih untuk mendokumentasikan ini di halaman manual daripada memperbaikinya tampaknya menunjukkan bahwa ada alasan yang sah mengapa pthread_cond_waitakhirnya bangun dengan palsu. Agaknya, ada sesuatu yang intrinsik tentang cara kerjanya yang membuatnya sehingga tidak dapat membantu. Pertanyaannya adalah apa.

Mengapa tidak pthread_cond_waitkembali spuriously? Mengapa tidak bisa menjamin bahwa itu hanya akan bangun ketika sudah diberi sinyal dengan benar? Adakah yang bisa menjelaskan alasan perilakunya yang palsu?

Penjelasan berikut diberikan oleh David R. Butenhof dalam "Programming with POSIX Threads" (hlm. 80):

Wake up palsu mungkin terdengar aneh, tetapi pada beberapa sistem multiprosesor, membuat wakeup kondisi sepenuhnya dapat diprediksi secara substansial mungkin memperlambat semua operasi variabel kondisi.

Dalam diskusi comp.programming.threads berikut , ia memperluas pemikiran di balik desain:

Patrick Doyle menulis: 
> Dalam artikel, Tom Payne menulis: 
>> Kaz Kylheku menulis: 
>>: Karena implementasi terkadang tidak dapat menghindari memasukkan 
>>: wakeups palsu ini; mungkin mahal untuk mencegahnya.

>> Tapi mengapa? Mengapa ini sangat sulit? Sebagai contoh, apakah kita sedang membicarakan
>> situasi di mana waktu tunggu habis tepat saat sinyal tiba? 

> Anda tahu, saya ingin tahu apakah para perancang pthreads menggunakan logika seperti ini: 
> Pengguna variabel kondisi harus memeriksa kondisi saat keluar, 
> jadi kami tidak akan menempatkan beban tambahan pada mereka jika kami mengizinkan 
> bangun palsu; dan karena dibayangkan itu memungkinkan palsu
> wakeups bisa membuat implementasi lebih cepat, itu hanya bisa membantu jika kita 
> izinkan mereka. 

> Mereka mungkin tidak memiliki implementasi tertentu dalam pikiran. 

Anda sebenarnya tidak jauh sama sekali, kecuali Anda tidak mendorongnya cukup jauh. 

Tujuannya adalah untuk memaksakan kode yang benar / kuat dengan memerlukan loop predikat. Ini
didorong oleh kontingen akademis yang terbukti benar di antara "inti benang" di Indonesia 
kelompok kerja, meskipun saya tidak berpikir ada yang benar-benar tidak setuju dengan maksud tersebut 
begitu mereka mengerti apa artinya. 

Kami mengikuti niat itu dengan beberapa tingkat pembenaran. Yang pertama adalah itu
"religius" menggunakan loop melindungi aplikasi terhadap ketidaksempurnaannya sendiri 
praktik pengkodean. Yang kedua adalah tidak sulit membayangkan secara abstrak
mesin dan kode implementasi yang dapat memanfaatkan persyaratan ini untuk meningkatkan 
kinerja kondisi rata - rata menunggu operasi melalui optimalisasi 
mekanisme sinkronisasi. 
/ ------------------ [David.Buten ... @ compaq.com] ------------------ \ 
| Compaq Computer Corporation, Arsitek POSIX Thread |
| Buku saya: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\ ----- [http://home.earthlink.net/~anneart/family/dave.html] ----- / 

Setidaknya ada dua hal 'bangun palsu' bisa berarti:

• Utas yang diblokir pthread_cond_waitdapat kembali dari panggilan meskipun tidak ada panggilan ke pthread_call_signalatau pthread_cond_broadcastpada kondisi yang terjadi.
• Utas diblokir sebagai pthread_cond_waitbalasannya karena panggilan ke pthread_cond_signalatau pthread_cond_broadcast, namun setelah mendapatkan kembali mutex, predikat yang mendasarinya ternyata tidak lagi benar.

Tetapi kasus terakhir dapat terjadi bahkan jika implementasi variabel kondisi tidak memungkinkan kasus sebelumnya. Pertimbangkan antrean konsumen produsen, dan tiga utas.

• Thread 1 baru saja mengeluarkan elemen dan merilis mutex, dan antrian sekarang kosong. Thread melakukan apa pun yang dilakukannya dengan elemen yang diperolehnya pada beberapa CPU.
• Thread 2 mencoba untuk mengeluarkan elemen, tetapi menemukan antrian kosong ketika diperiksa di bawah mutex, panggilan pthread_cond_wait, dan blokir dalam panggilan menunggu sinyal / siaran.
• Thread 3 mendapatkan mutex, memasukkan elemen baru ke dalam antrian, memberitahukan variabel kondisi, dan melepaskan kunci.
• Menanggapi pemberitahuan dari utas 3, utas 2, yang menunggu dengan syarat, dijadwalkan untuk berjalan.
• Namun sebelum utas 2 mengelola CPU dan mengambil kunci antrian, utas 1 menyelesaikan tugasnya saat ini, dan kembali ke antrian untuk pekerjaan lebih lanjut. Ia mendapatkan kunci antrian, memeriksa predikat, dan menemukan bahwa ada pekerjaan dalam antrian. Itu melanjutkan untuk mengeluarkan item yang dimasukkan thread 3, melepaskan kunci, dan melakukan apa pun yang dilakukan dengan item yang di-thread 3 enqueued.
• Thread 2 sekarang mendapatkan CPU dan mendapatkan kunci, tetapi ketika memeriksa predikat, ia menemukan bahwa antrian kosong. Thread 1 'mencuri' item, sehingga bangun tampaknya palsu. Thread 2 perlu menunggu pada kondisi lagi.

Jadi karena Anda sudah selalu perlu memeriksa predikat di bawah satu lingkaran, tidak ada bedanya jika variabel kondisi yang mendasari dapat memiliki jenis lain dari bangun palsu.

Bagian "Kebangkitan Berganda oleh Sinyal Kondisi" di pthread_cond_signal memiliki contoh implementasi pthread_cond_wait dan pthread_cond_signal yang melibatkan wakekup palsu.

Sementara saya tidak berpikir itu dianggap pada saat desain, berikut adalah alasan teknis sebenarnya: Dalam kombinasi dengan pembatalan ulir, ada beberapa kondisi di mana mengambil opsi untuk membangunkan "secara palsu" mungkin benar-benar diperlukan, setidaknya kecuali Anda Bersedia memberikan batasan yang sangat kuat pada strategi implementasi seperti apa yang mungkin.

Masalah utama adalah bahwa, jika sebuah thread bekerja pada pembatalan saat diblokir pthread_cond_wait, efek sampingnya haruslah seolah-olah tidak mengkonsumsi sinyal apa pun pada variabel kondisi. Namun, sulit (dan sangat membatasi) untuk memastikan bahwa Anda belum mengkonsumsi sinyal ketika Anda mulai bertindak pada pembatalan, dan pada tahap ini mungkin tidak mungkin untuk "memposting ulang" sinyal ke variabel kondisi, karena Anda mungkin berada dalam situasi di mana penelepon pthread_cond_signalsudah dibenarkan telah menghancurkan condvar dan membebaskan memori di mana ia tinggal.

Penyisihan untuk bangun palsu memberi Anda jalan keluar yang mudah. Alih-alih terus bertindak atas pembatalan ketika tiba sementara diblokir pada variabel kondisi, jika Anda mungkin telah mengkonsumsi sinyal (atau jika Anda ingin malas, tidak peduli apa), Anda dapat mendeklarasikan bahwa peringatan palsu telah terjadi sebagai gantinya, dan kembali dengan sukses. Ini sama sekali tidak mengganggu operasi pembatalan, karena penelepon yang benar hanya akan bertindak pada pembatalan yang tertunda saat berikutnya ia mengulang dan menelepon pthread_cond_waitlagi.