Kenapa RTOS dianggap deterministik?

Pada pc (tentu saja OS) setiap program C menjadi tidak pasti dalam hal waktu. Misalnya loop membutuhkan waktu antara 1,2 dan 1,3 detik tergantung pada "seberapa cepat saya memindahkan jendela lain". Itu karena OS membuat proses (atau utas) berbagi kekuatan pemrosesan.

Sejauh menyangkut RTOS (pada sistem tertanam), ketika kita menulis aplikasi multithreading, saya pikir hal yang sama terjadi tergantung pada berapa banyak thread yang dieksekusi secara bersamaan.

Saya tidak memiliki instrumen untuk menguji ini secara akurat pada sistem tertanam. Jadi, saya ingin bertanya. Apakah kekhawatiran saya masuk akal atau saya melewatkan sesuatu yang sangat mendasar?

EDIT : Saya akan memberikan contoh. kami memiliki task1 (membutuhkan 10 ms) dan task2 (membutuhkan 20 ms). Mereka memulai pada saat yang sama pada dua utas yang terpisah. Klaim saya (juga menyangkut, tidak yakin) adalah bahwa task1 membutuhkan lebih dari 10ms, karena mereka berbagi kekuatan pemrosesan dengan task2.

Tidak benar bahwa tugas-tugas dalam RTOS secara otomatis bersifat deterministik, tetapi dimungkinkan untuk memberikan batasan yang lebih ketat tentang kapan dan seberapa sering tugas berjalan. RTOS biasanya akan menyediakan prioritas berat untuk tugas-tugas; kapan saja tugas siap dengan prioritas tertinggi sedang berjalan. Penulis kode juga memiliki kendali total atas serangkaian tugas yang sedang dijalankan; Anda bisa berharap tidak ada tugas latar belakang prioritas tinggi yang dapat mengganggu kode Anda untuk, katakanlah, bertukar data ke disk, kecuali jika Anda menulisnya.

Selain itu, beberapa RTOS menyediakan multitasking kooperatif. Berbeda dengan multitasking preemptive, dengan multitasking kooperatif tugas akan terus dijalankan sampai secara sukarela menyerahkan kontrol CPU.

Sejauh menyangkut RTOS (pada sistem tertanam), ketika kita menulis aplikasi multithreading, saya pikir hal yang sama terjadi tergantung pada berapa banyak thread yang dieksekusi secara bersamaan.

NGGAK!

Jika itu terjadi, maka itu bukan REAL-TIME OS (RTOS).

Jawaban singkatnya adalah bahwa definisi RTOS tidak ada hubungannya dengan multi-tasking atau prioritas. Sederhananya semua tugas memiliki jaminan waktu .

Sisa dari apa yang Anda anggap sebagai karakteristik RTOS (penentuan prioritas, penyelesaian tugas, dll) hanyalah konsekuensi (atau fitur) dari membangun sistem di mana tugas harus diselesaikan dalam interval waktu yang ditentukan.

Multi-tasking dalam RTOS secara konseptual lebih sederhana daripada di OS waktu lunak karena banyak kasus tepi yang rumit pada dasarnya tidak diperbolehkan.

RTOS biasanya tidak menjamin throughput , melainkan memungkinkan Anda untuk menjamin latensi .

Ini biasanya dicapai dengan sistem prioritas, seperti di sini di FreeRTOS:

Penjadwal FreeRTOS memastikan bahwa tugas-tugas dalam status Ready atau Running akan selalu diberi waktu prosesor (CPU) dalam preferensi untuk tugas-tugas dengan prioritas lebih rendah yang juga dalam status siap. Dengan kata lain, tugas yang ditempatkan dalam status Running selalu merupakan tugas dengan prioritas tertinggi yang dapat dijalankan.

Misalkan Anda memiliki tugas prioritas 1 yang membutuhkan waktu 10 ms untuk menangani suatu peristiwa, tugas prioritas 2 yang membutuhkan 100 ms untuk menangani acara yang berbeda, dan tugas prioritas 3 latar belakang. Jika Anda mengharapkan untuk mendapatkan satu acara prioritas 1 tidak lebih dari setiap detik, Anda dapat mengatakan bahwa kasus terburuk untuk menangani acara prioritas 2 adalah 10ms + 100ms. Tugas prioritas 3 mungkin secara sewenang-wenang diperlambat oleh kejadian, tetapi Anda tidak peduli - karena prioritasnya rendah.

Saya lebih suka ini menjadi komentar tetapi terlalu banyak karakter. Ngomong-ngomong, ozgur, menilai dari pertanyaan-pertanyaan dalam tanggapan komentar Anda, Anda sepertinya kehilangan poin bahwa Anda tidak bisa hanya mengatakan bahwa utas saya membutuhkan waktu lama untuk berjalan dan mengharapkannya berfungsi secara ajaib dalam hubungannya dengan utas lainnya semua berkat OS. Anda harus merancang utas Anda dan menganalisisnya untuk kinerja kasus terburuk. Jika kasus terburuk tidak memenuhi persyaratan Anda, maka Anda perlu mendesain ulang utas Anda.

Jadi daripada hanya mengatakan thread 1 membutuhkan 10 ms untuk menyelesaikan dan utas 2 membutuhkan 20 ms, Anda juga harus mengatakan utas 1 harus dijalankan setiap 15 ms. utas 2 harus dijalankan setiap 40 ms. utas 3 harus menjalankan setiap 500 ms, utas harus menjalankan setiap 1500 ms. Lalu Anda mengalokasikan waktu untuk berapa lama setiap utas dapat menyelesaikan dalam skenario kasus terburuk. Anda menyatukan semua itu, mengidentifikasi skenario yang paling buruk dan kemudian Anda harus memastikan setiap utas memenuhi persyaratan waktu. Analisis ini juga di mana Anda mengidentifikasi jika beberapa utas perlu prioritas lebih tinggi daripada yang lain untuk memenuhi persyaratan waktu mereka.

Sebagai contoh, thread5 sedang berjalan akan terganggu oleh thread 4 yang akan terganggu oleh thread 3 yang akan terganggu oleh threadN mungkin menjadi salah satu skenario terburuk. Anda meletakkan semua ini di timeline dan memverifikasi bahwa bahkan dalam skenario terburuk ini setiap utas memenuhi persyaratan waktunya. Anda dapat memastikan utas menyelesaikan skenario kasus terburuk ini secara deterministik dengan menggunakan penjadwal dan prioritas dalam OS waktu nyata. Determinisme itulah yang membuat OS waktu nyata.

Jika Anda membuat utas sebagai prioritas yang sama maka Anda telah kehilangan sebagian (jika tidak semua) determinisme itu karena penjadwal mungkin bebas untuk memilih utas mana yang ingin dijalankan selanjutnya.

Dalam OS seperti Windows, Anda tidak hanya tidak dapat menentukan kapan setiap utas akan berjalan, Anda bahkan tidak dapat menjamin bahwa aplikasi Anda akan berjalan pada suatu titik waktu. OS dapat menghentikan aplikasi Anda dan menjalankan beberapa layanan latar belakang kapan pun ia mau. Dengan kata lain, tidak ada determinisme. Jadi, Windows bukan OS waktu-nyata. Meskipun, jika persyaratan waktu Anda besar, seperti (thread1 berjalan setiap 10 detik, thread2 berjalan setiap 15 detik) maka Anda pada dasarnya dapat memperlakukan Windows seperti OS waktu nyata selama Anda menghitung slop dan kira-kira setiap 10 atau 15 detik (memberi atau mengambil beberapa ratus milidetik dan jendela yang sering terlewat) cukup baik.

Meskipun jawaban lain telah menyatakan bahwa di "dunia nyata" skenario Anda tidak mungkin, untuk dapat menjawab pertanyaan Anda, kami harus membangun sistem hipotetis .

Sistem kami terdiri dari pistol yang menembak bola dengan kecepatan tetap, dua kotak yang "menangkap" bola dan maju satu langkah dengan setiap bola ditangkap. Pistol dapat diaktifkan untuk menembak ke salah satu kotak tetapi kehilangan satu bola setiap kali diaktifkan. Kotak pertama akan membutuhkan 1000 langkah (bola) untuk mencapai ujungnya dan kotak 2 akan membutuhkan 2000.

Skenario 1 (tugas satu demi satu):
- Pistol menembak 1000 bola di kotak 1, beralih (biaya 1 bola) dan menembak 2.000 bola di kotak 2, dengan total 3001 bola .

Skenario 2 (tugas "simultan"):
- Pistol menembak 5 bola di satu kotak, mengganti dan menembak 5 bola di kotak lainnya untuk memberikan tampilan simultan . Biaya pengalihan adalah (1000/5 x 2 =) 400 bola. Jadi, setelah menembak 2400 bola, kotak 1 akan mencapai ujungnya dan kotak 2 akan membutuhkan 1000 bola tambahan untuk mencapai ujungnya, dengan total 3400 bola .

Menerapkan hasil ini ke skenario Anda, Tugas 1 dan paruh pertama Tugas 2 akan selesai setelah 24 ms, dan paruh kedua Tugas 2 akan selesai dalam 10 ms tambahan untuk total 34 ms. Ini jelas menunjukkan bahwa waktu yang diperlukan untuk menyelesaikan tugas meningkat karena waktu yang hilang dalam beralih di antara tugas . Hasil ini juga setara dengan Tugas 1 mengambil 12 ms dan Tugas 2 mengambil 22 ms, untuk menyelesaikan.