Jawaban sederhananya adalah tidak semua utas mengeksekusi secara bersamaan. Untuk penjelasan lebih lengkap, baca terus.
Penjadwal tugas sistem operasi umumnya dianggap untuk menjadwalkan aplikasi, dan dengan demikian memungkinkan Anda untuk melakukan satu tugas saat komputer sedang mengerjakan yang lain. Di masa lalu, tes lakmus multitasking adalah memformat floppy disk saat melakukan sesuatu yang lain. Jika Anda benar-benar ingin menguji OS, Anda akan memformat floppy disk saat mengunduh file melalui modem yang terhubung ke port serial. Karena perangkat keras menjadi cukup kuat untuk benar-benar melakukannya dengan cara yang bermakna, pemutaran video kadang-kadang juga ditampilkan dalam pengujian tersebut. Jika penjadwal tugas OS dapat menangani menjalankan tugas-tugas itu dengan lancar, maka itu dapat menangani apa pun.
Namun, penjadwal tugas tidak benar-benar menjadwalkan aplikasi (proses), itu menjadwalkan utas . Setiap aplikasi memiliki setidaknya satu utas, tetapi berpotensi dapat menggunakan sejumlah besar utas untuk membagi pekerjaan yang dilakukannya menjadi bagian terkait atau independen. Misalnya, adalah umum untuk aplikasi memiliki satu utas yang menangani antarmuka pengguna, dan untuk membuat utas lain ketika pengguna memulai operasi yang berpotensi berjalan lama (yang mungkin seperti mencetak, menghitung ulang spreadsheet, lingkungan pengembangan melakukan pencarian simbol, dll. dll). Beberapa lingkungan pemrograman memperkenalkan sejumlah utas tanpa terlihat ke programmer; misalnya, Java dan .NET mungkin melakukan pengumpulan sampahdi utas terpisah, yang berada di luar kendali langsung programmer. Beberapa program membuat sejumlah utas sejak awal dan menggabungkannya, karena membuat utas baru adalah operasi yang relatif mahal (jadi Anda tidak perlu harus membuat utas setiap kali Anda membutuhkannya). Apa pun yang melakukan pratinjau biasanya dilakukan di utas terpisah, sehingga sisa UI tetap responsif saat pratinjau sedang dibuat. Dan seterusnya. Secara keseluruhan, semua ini berarti bahwa jumlah utas pada sistem setiap saat dapat dengan mudah beberapa kali lipat dari jumlah proses.
Setiap utas dapat berada dalam salah satu dari beberapa keadaan yang mungkin, tetapi perbedaan yang paling penting adalah antara kondisi berlari , runnable , dan menunggu ; terminologinya bisa sedikit berbeda, tapi itulah ide umumnya. Pada suatu saat, hanya satu utas per virtual (karena teknologi hyperhreading dan sejenisnya) inti CPU dapat berjalan (yaitu, menjalankan instruksi kode mesin), tetapi sejumlah utas dapat runnable (artinya adalah kandidat untuk mendapatkan CPU waktu berikutnya penjadwal perlu membuat keputusan tentang utas yang harus dijalankan). Menunggu (juga dikenal sebagai diblokir) utas hanya itu, menunggu sesuatu - kasus yang paling umum mungkin adalah bahwa itu sedang menunggu pengguna, disk atau I / O jaringan (input pengguna khususnya sangat lambat).
Jumlah utas yang Anda lihat di pengelola tugas adalah jumlah total utas di salah satu dari status ini. Sebagai contoh, sistem Windows 7 yang saya ketikkan ini saat ini memiliki sekitar 70 proses dimulai tetapi hampir 900 utas. Dengan semua proses latar belakang untuk menangani berbagai tugas dan bagaimana masing-masing tugas dibagi menjadi banyak utas, ini bukan angka yang keterlaluan.
Melangkah lebih jauh ke kedalaman implementasi teknis, pada inti dari penjadwal tugas sistem operasi multitasking pre-emptively biasanya beberapa jenis kait interupsi perangkat keras. Ini berarti bahwa kernel dapat menghentikan CPU ketika tidak memiliki pekerjaan yang berguna untuk melakukan (ini hampir pasti salah satu alasan, jika tidak dengan alasan, mengapa Linux pemeriksaan yang HLTinstruksi pada boot pada IA-32CPU -compatible, dan mungkin melakukan pemeriksaan serupa pada arsitektur lain), aman dalam pengetahuan bahwa pada beberapa waktu yang cukup menentukan di masa depan, sebuah interupsi akan menyala dan penjadwal tugas akan dipanggil. Karena api interupsi terlepas dari pekerjaan apa yang dilakukan CPU (itulah ide di balik interupsi), penjadwal akan dieksekusi secara teratur dan mendapat kesempatan untuk menentukan utas mana yang harus dieksekusi selama irisan waktu berikut. Karena sakelar konteks relatif mahal, biasanya dimungkinkan (setidaknya melalui kode sumber) untuk menyesuaikan seberapa agresif penjadwal beralih di antara utas; switching threads lebih sering menyebabkan sistem menjadi lebih responsif, tetapi switching overhead berarti bahwa keseluruhan waktu untuk menyelesaikan serangkaian tugas yang diberikan lebih lama. The tercepatsistem akan menjadi salah satu yang hanya beralih di antara utas ketika utas yang berjalan tidak lagi dapat dijalankan (artinya ia diblokir menunggu sesuatu, atau telah menyelesaikan tugasnya) karena itu meminimalkan overhead, sedangkan sistem yang paling responsif akan beralih di antara utas setiap kali scheduler dipanggil karena meminimalkan waktu rata-rata untuk menunggu sebelum utas tertentu mendapat waktu CPU. Pengaturan yang ideal biasanya ada di antara keduanya, dan pertukaran antara pilihan-pilihan itu kemungkinan merupakan salah satu alasan utama mengapa Linux menawarkan beberapa penjadwal untuk dipilih dan juga beberapa parameter penyetelan melalui konfigurasi kernel.
Sebaliknya, OS dan lingkungan yang bekerja sama secara kooperatif ( Windows 3.x menjadi salah satu contoh), bergantung pada setiap aplikasi untuk secara teratur menyerahkan kontrol ke penjadwal. Biasanya ada fungsi API yang secara khusus dimaksudkan untuk melakukan itu, dan seringkali banyak fungsi API akan melakukannya sebagai bagian dari alur eksekusi internal mereka, karena itu membantu membuat pengalaman pengguna lebih lancar. Pendekatan desain itu bekerja dengan baik selama semua aplikasi berperilaku baik dan memberikan kontrol dengan interval pendek selama setiap operasi yang berjalan lama (arti berjalan lebih dari sepersekian detik), tetapi aplikasi yang tidak dapat menyumbat seluruh sistem. Ini adalah salah satu alasan utama mengapa Windows 3.x melakukannya dengan buruk pada tes multitasking yang saya sebutkan di atas, sementara OS / 2berjalan dengan riang sambil melakukan tugas yang sama pada perangkat keras yang sama: aplikasi dapat memberitahu floppy disk drive untuk menulis sektor tertentu, dan waktu yang dibutuhkan untuk melakukannya sebelum panggilan kembali sebenarnya dapat diukur (puluhan hingga ratusan milidetik atau lebih); sistem preemptively multitasking akan memiliki penjadwalan masuk pada jadwal doa berikutnya, perhatikan bahwa utas yang saat ini "berjalan" sebenarnya diblokir oleh panggilan tulis dan hanya beralih ke utas lain yang dapat dijalankan. (Dalam praktiknya itu sedikit lebih terlibat, tapi itu ide umum.)
Dalam lingkungan multitasking dan kooperatif yang preemptively, ada juga kemungkinan utas yang berbeda memiliki prioritas yang berbeda. Sebagai contoh, mungkin lebih penting untuk mengeksekusi secara tepat waktu utas yang menerima data melalui tautan komunikasi daripada yang memperbarui tampilan waktu sistem, sehingga utas penerima memiliki prioritas tinggi dan waktu yang menampilkan utas updater memiliki prioritas rendah . Prioritas utas berperan dalam keputusan penjadwal mana utas yang diizinkan untuk dieksekusi (misalnya, sangat disederhanakan, utas prioritas tinggi harus selalu dijalankan sebelum utas prioritas rendah, sehingga bahkan jika utas prioritas rendah masih berfungsi, jika utas prioritas tinggi menjadi runnable akan diutamakan), tetapi keputusan penjadwalan khusus tersebut tidak mempengaruhi desain mekanisme yang mendasarinya.