Apakah penjadwalan koperasi menunda proses ketika mereka melakukan operasi I / O?

19

Banyak referensi sistem operasi mengatakan bahwa dengan multitasking kooperatif (berlawanan dengan preemptive), sebuah proses menjaga CPU sampai secara eksplisit secara sukarela menangguhkan dirinya. Jika proses yang berjalan melakukan permintaan I / O yang tidak dapat segera dipenuhi (mis., Permintaan stroke kunci yang belum tersedia), apakah penjadwal menunda itu, atau apakah itu benar-benar menjaga CPU sampai permintaan dapat dilayani?

[Diedit untuk mengganti "blok pada i / o" dengan "melakukan permintaan I / O yang tidak dapat segera dipenuhi."]

operating-systems process-scheduling

— Ellen Spertus
sumber

Pertanyaan-pertanyaan ini tampaknya menanyakan secara spesifik sistem operasi yang, imho, akan menjadi offtopic di sini. Jika bukan ini masalahnya, ulangi pertanyaan Anda menjadi pertanyaan yang lebih abstrak.

— Raphael

3

Ketika saya mempostingnya ke grup Unix, saya diberitahu itu tidak pantas di sana dan milik di sini, yang saya setujui, karena ini bukan tentang satu sistem operasi tertentu. Saya pikir yang satu ini sebanding dengan pertanyaan tentang prediksi cabang. Akan menarik untuk melihat apa yang diputuskan oleh masyarakat tentang apa yang layak dan tidak pantas di sini.

— Ellen Spertus

15

Dalam pengaturan yang benar-benar "kooperatif", dan jika tidak ada perlindungan perangkat keras, suatu proses tentu saja dapat memblokir I / O dan tidak melepaskan kontrol sampai I / O selesai (atau tidak pernah melepaskan kontrol sama sekali). Sebagai contoh, Windows 3.1 dengan cara ini: jika satu proses pengguna ingin mengambil alih seluruh komputer, dan mencegah hal lain berjalan, itu bisa.

Tetapi pada sistem dengan multitasking, Anda mengharapkan perintah API I / O sistem untuk melepaskan kendali prosesor ketika mereka dipanggil. Jadi ketika proses yang berjalan memblokir pada I / O, dengan asumsi bahwa proses tersebut menggunakan API sistem normal, proses lain akan diizinkan untuk berjalan sampai I / O selesai, dan akhirnya proses asli akan dilanjutkan setelah I / O selesai. . Dengan kata lain, memanggil fungsi I / O pemblokiran adalah salah satu cara agar suatu proses pada sistem koperasi dapat secara sukarela menangguhkan dirinya sendiri.

— Carl Mummert
sumber

11

Jika proses yang berjalan diblokir pada i / o

Memblokir di IO hampir sama dengan menunda proses Anda. Dalam konteks kernel linux, mengeksekusi beberapa pemanggilan sistem IO seperti read()akan menyebabkan sysenterpengendali atau interupsi pemicu untuk menjaga IO itu, do_sys_read()akhirnya memanggil . Di sini, jika permintaan saat ini tidak dapat segera dipenuhi, fungsi panggilan sched()yang kemudian dapat menjalankan proses lain.

Dalam konteks sistem koperasi, saya berharap bahwa ketika Anda membuat panggilan sistem untuk beberapa alasan IO, jika permintaan tidak dapat dipenuhi, kernel memilih tugas lain dan menjalankannya. Dokumen ini memberikan latar belakang - pada dasarnya, jika Anda menunggu di IO, Anda bisa digantung selamanya menunggu IO itu. Gagasan penjadwalan koperasi adalah bahwa Anda sering memanggil sched()atau metode pelepasan cpu yang sama, jika melakukan tugas-tugas yang intensif CPU.

Pertimbangan mode kernel menjadi lebih menarik. Pada arsitektur di mana mereka tersedia seperti platform tertanam tertentu , penangan interupsi masih akan dipanggil sebagai respons terhadap interupsi perangkat keras atau lunak. Biasanya dimungkinkan, implementasi-bijaksana, untuk menonaktifkan penanganan interupsi , tetapi itu juga memiliki kelemahan.

4

Dalam model penjadwalan kooperatif (lebih disukai cooperative multitasking), tidak ada konsep penjadwal dalam arti bahwa sistem operasi tidak memiliki kendali atas berapa lama proses berjalan.

Aplikasi yang diprogram dengan benar akan secara sukarela menyerahkan CPU pada I / O. Tetapi, aplikasi yang ditulis dengan buruk mungkin hanya terus menunggu di I / O, sehingga menghalangi proses lainnya.

PS: Pendekatan ini kemudian diserahkan oleh sebagian besar OS yang mendukung preemptive-scheduling (yang memiliki scheduler eksternal) dan sekarang kami memiliki semua jenis algoritma penjadwalan yang berbeda yang digunakan oleh OS yang berbeda.

EDIT: Jawaban saya didasarkan pada penjadwalan seperti yang dijelaskan dalam bentuk aslinya (tahun lalu: P). Ketika Gilles berkomentar beberapa sistem masih menggunakan penjadwalan kooperatif. Dan ada scheduler. Saya tidak yakin apakah sistem itu menggunakan COS dalam bentuk aslinya dan murni.

— Ankit
sumber

2

Banyak embedded OS (termasuk tetapi tidak terbatas pada RTOS) memiliki penjadwalan kooperatif. Ini bukan untuk mengatakan tidak ada penjadwal; scheduler adalah kode yang menentukan utas mana yang akan dijalankan selanjutnya. Preemption adalah tentang penjadwal yang dimasukkan secara otomatis sebagai lawan atas permintaan tugas yang sedang berjalan.

— Gilles 'SO- stop being evil'

@Gilles Komentar yang bagus (disunting). Saya setuju dengan Anda bahwa itu tidak sepenuhnya tidak digunakan. Jawaban saya hanya didasarkan pada algoritma seperti yang didefinisikan pada awalnya. AFIK, digunakan dengan beberapa modifikasi (dengan beberapa scheduler). Saya tidak yakin apakah itu digunakan dalam bentuk murni di beberapa OS.

— Ankit

4

Koperasi multitasking menyiratkan bahwa konteks pelaksana harus secara eksplisit melepaskan kontrol ke penjadwal, dan jika diinginkan, dapat mencegah terjadinya perubahan konteks.

Sebagian besar implementasi secara eksplisit melakukan saklar konteks untuk panggilan sistem apa pun yang tidak segera kembali, dan sering bahkan jika itu terjadi, untuk meningkatkan keadilan alokasi prosesor.

Biasanya hanya mungkin untuk proses yang gagal (atau sengaja menolak layanan untuk sisa sistem) untuk mencegah pengalihan tugas yang sering.

Pre-emption, seperti yang dijelaskan oleh Gilles, adalah batasan arsitektur sistem yang mencegah terputusnya waktu tugas aktif dan sakelar konteks paksa.

— Pekka
sumber