Praktik terbaik bukan untuk polling ... tetapi bukankah polling terjadi secara internal ketika utas panggilan menunggu ()?

Katakanlah kita memiliki beberapa utas yang ingin memeriksa kapan utas lain selesai tugasnya. Saya telah membaca bahwa kita harus memanggil fungsi tipe wait () yang akan membuat utas ini menunggu hingga menerima pemberitahuan bahwa utas lainnya selesai. Dan ini bagus karena itu berarti kami tidak melakukan polling yang mahal.

Tetapi bukankah pemungutan suara terjadi secara internal di tingkat yang lebih rendah? Yaitu jika kita membuat utas menunggu () bukankah kernal melakukan polling untuk memeriksa kapan utas lainnya selesai sehingga kemudian dapat memberi tahu utas pertama?

Saya kira saya kehilangan sesuatu di sini, dapatkah seseorang mencerahkan saya?

parallelism multithreading locks

— csss
sumber

Sistem operasi menyediakan primitif tertentu untuk jenis komunikasi antar proses yang tidak memerlukan polling.

Jika proses A menunggu di mutex M, OS tahu A tidak dapat dijalankan dan menyimpannya di samping proses menunggu sesuatu terjadi. Ketika proses menahan M melepaskannya, OS melihat daftar proses yang menunggunya. Proses pertama dalam daftar, mungkin A, akan dihapus dari ember siaga dan dimasukkan ke dalam antrian run . Waktu berikutnya A mendapat irisan waktu, wait () yang dipanggil akan kembali dan program berlanjut.

— Blrfl
sumber

jadi dengan cara itu pemungutan suara tetapi pada tingkat OS?

— tgkprog

Tidak @tgkprog, ini bukan polling, karena proses menunggu tidak dijadwalkan untuk berjalan sampai OS atau proses lain melepaskan mutex. Proses pemungutan suara akan terus bersaing dalam penjadwalan cpu untuk memeriksa apakah harus berhenti menunggu. Proses pemungutan suara semacam ini dapat membakar sebagian besar waktu CPU saat menunggu.

— joshp

i berarti proses OS polling status mutex. meskipun saya yakin itu dioptimalkan dan lebih baik dari apa pun yang bisa kami lakukan. mungkin berjalan sebagai bagian dari penjadwal.

— tgkprog

@ tgkprog: OS tidak menaruh sedikit perhatian pada apa yang terjadi dengan mutex sampai proses menahannya melepaskannya atau berakhir. Salah satu dari peristiwa tersebut akan menyebabkan OS menyerahkan kunci mutex ke proses apa pun yang pertama kali dalam daftar tunggu dan menandai proses tersebut sebagai runnable. Tidak ada pemungutan suara yang terlibat, hanya menanggapi suatu peristiwa. Semua yang dikatakan joshp disertakan dengan referensi. :-)

— Blrfl

@csss: Cukup banyak. Proses dapat berakhir secara sukarela (misalnya, memanggil _exit(2)sistem POSIX-y) atau tanpa sengaja (misalnya, kesalahan seperti divide-by-zero menghasilkan interupsi atau panggilan lain kill(2)). Dalam kedua kasus, kontrol secara eksplisit diserahkan kembali ke OS, yang tahu proses apa yang sedang berjalan atau harus dibunuh. Tugas untuk mengakhiri suatu proses termasuk membebaskan sumber dayanya, termasuk mutex. Jika mutex dipegang oleh proses yang sekarang mati, OS akan merilisnya. Jika prosesnya ada di daftar tunggu mutex, itu akan dihapus.

— Blrfl