Wawancara Sistem Operasi: Bagaimana Priority Inversion Terjadi, dan Apa yang Dijamin oleh Priority Inheritance?

Prompt dan Konteks yang Berlaku

Sistem real-time preemptive dengan fixed-priority pada single-core memiliki tiga task. Angka prioritas yang lebih besar berarti prioritas yang lebih tinggi:

Pada t=0, L memiliki mutex tersebut. H kemudian bangun, mem-preempt L, mencoba mengambil mutex, dan terblokir (blocks). Setelah H terblokir selama 1ms, M menjadi runnable. Jelaskan urutan eksekusi dengan mutex biasa dan dengan priority inheritance, hitung batas waktu tunggu lock H, dan bahas hal-hal berikut:

• apa yang membuat kasus ini menjadi sebuah priority inversion yang unbounded;
• bagaimana prioritas dipropagasikan dan dipulihkan dengan multiple mutexes, waiters, dan nested blocking;
• trade-off antara protokol priority inheritance dan priority-ceiling;
• mengapa semaphore biasa, time slice yang lebih pendek, atau menaikkan kembali prioritas H bukanlah perbaikan yang setara;
• bagaimana scheduler trace dan metrik deadline dapat membuktikan bahwa perbaikan tersebut berhasil.

Pertanyaan ini cocok untuk peran embedded, RTOS, real-time Linux, robotika, audio/video, industrial-control, dan systems-software. Nilai prioritas serta 3ms, 20ms, dan 10ms merupakan batasan latihan, bukan klaim tentang rentang prioritas RTOS tertentu atau ambang batas produksi.

Apa yang Sedang Dievaluasi oleh Pewawancara

Lapisan pertama adalah memisahkan pemblokiran sumber daya langsung (direct resource blocking) dari penundaan yang disebabkan oleh pekerjaan yang tidak terkait. H yang menunggu L melepaskan sumber daya sudah merupakan sebuah priority inversion. Bagian yang merusak prediktabilitas adalah bahwa M tidak menggunakan sumber daya tersebut namun dapat berulang kali mem-preempt pemilik lock berprioritas rendah, L, sehingga memperpanjang waktu tunggu H dengan sejumlah pekerjaan prioritas menengah yang arbitrer.

Lapisan kedua adalah menggambarkan urutan peristiwa alih-alih sekadar membaca definisi dari hafalan. Dengan mutex biasa, L berstatus runnable setelah H terblokir, tetapi di-preempt saat M bangun. H menunggu selama 20ms milik M ditambah sisa 3ms milik L, yaitu sekitar 23ms, yang melebihi deadline 10ms. Dengan inheritance, H mendonasikan prioritas efektif 90 kepada L tepat pada saat H terblokir. M tidak dapat mem-preempt L, sehingga berdasarkan asumsi pada prompt, H menunggu sekitar sisa 3ms milik L ditambah overhead scheduler.

Lapisan ketiga adalah memahami state implementasi. Sebuah lock membutuhkan pemilik (owner) dan antrean waiter yang terurut berdasarkan prioritas. Ketika sebuah task memiliki beberapa lock, prioritas efektifnya adalah nilai maksimum dari prioritas dasarnya dan setiap donasi yang aktif. Jika waiter berprioritas tertinggi mengalami timeout, dibatalkan, atau berhenti menunggu karena sebuah lock dilepaskan, prioritas harus dihitung ulang dan bukan langsung di-reset begitu saja ke nilai dasar. Jika pemilik yang dinaikkan prioritasnya (boosted) terblokir pada lock lain, donasi harus dipropagasikan di sepanjang rantai PI.

Lapisan keempat adalah batasan mekanisme. Inheritance membatasi penundaan tak terbatas (unbounded delay) yang disebabkan oleh task-task berprioritas menengah. Ini tidak mempersingkat I/O di dalam critical section, wilayah interrupt-disabled, kode non-preemptible, atau operasi hardware, dan ini tidak menghilangkan deadlock. Priority ceiling menukar konfigurasi di awal dengan analisis blocking yang lebih statis. Counting semaphore tanpa pemilik tunggal tidak menyediakan task yang pasti untuk dinaikkan prioritasnya.

Terakhir, pewawancara menginginkan disiplin verifikasi. Jawaban yang kuat membandingkan durasi tunggu lock, durasi ketika L berstatus runnable tetapi tidak berjalan saat memegang lock, apakah M masuk ke dalam interval tersebut, kegagalan deadline H, serta jalur nested-lock dan timeout. Rata-rata utilisasi CPU atau pernyataan "sistem tidak hang" tidak membuktikan batas real-time.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Ke arah mana urutan prioritas berjalan, dan apa kebijakan scheduling-nya? Prompt menyatakan bahwa 90 lebih tinggi daripada 50 dan menetapkan preemption fixed-priority single-core. Beberapa RTOS memberi nomor prioritas ke arah sebaliknya, dan time-sharing scheduler standar tidak mendukung timeline yang sama secara langsung.
• Apakah 3ms merupakan wall-clock time atau waktu eksekusi CPU aktual? Di sini ini adalah sisa pekerjaan CPU milik L di dalam critical section. PI tidak dapat membuat device wait atau wilayah non-preemptible selesai lebih cepat secara fisik.
• Kapan deadline 10ms milik H dimulai? Di sini deadline dimulai saat H bangun. Jika deadline dimulai saat permintaan tiba atau pelepasan periodik, antrean sebelumnya juga harus dimasukkan ke dalam perhitungan response-time.
• Apakah ada interrupt atau task di atas prioritas 90? Latihan ini mengecualikannya dari perhitungan pertama. Batas di dunia nyata harus mencakup interferensi berprioritas lebih tinggi, waktu interrupt-disabled maksimum, overhead scheduler, dan efek cache.
• Apakah bus_mutex benar-benar merupakan mutex pelacak pemilik (owner-tracking)? Binary semaphore mungkin terlihat mirip tetapi tidak harus memiliki pemilik, unlock khusus pemilik, atau semantik PI.
• Apakah L memiliki lock lain atau sedang menunggu lock lain? Hal itu menentukan apakah donasi harus dipropagasikan secara rekursif dan mengubah analisis deadlock maupun batas blocking.
• Protokol apa yang didukung oleh implementasi target? POSIX menyediakan PTHREAD_PRIO_INHERIT dan PTHREAD_PRIO_PROTECT. Perilaku RTOS untuk multiple locks, timeout, recursive locks, dan deboosting berbeda-beda, sehingga dokumentasi versi yang tepat sangat berpengaruh.

Kerangka Jawaban 30 Detik

"Dengan mutex biasa, H terblokir karena L memiliki bus_mutex. L sebenarnya dapat menyelesaikan sisa 3ms pekerjaannya, tetapi setelah 1ms M pada prioritas 50 mem-preempt L pada prioritas 10 dan berjalan selama 20ms. M tidak pernah menyentuh mutex tetapi membuat H pada prioritas 90 menunggu secara tidak langsung. Oleh karena itu, waktu tunggu lock H adalah sekitar 20+3=23ms, melampaui deadline 10ms. Jika task-task berprioritas menengah terus berdatangan, panjang critical section L tidak lagi membatasi waktu tunggu ekstra tersebut.

Dengan priority inheritance, pemblokiran H menaikkan prioritas efektif L menjadi 90. M tidak dapat mem-preempt L setelah M bangun. L melepaskan mutex setelah sekitar 3ms, menghitung ulang prioritasnya dari waiter yang tersisa dan mutex yang dimiliki, lalu H memperoleh lock tersebut. PI mengontrol penundaan dari pekerjaan prioritas menengah yang tidak terkait. PI tidak menjanjikan zero blocking atau memperbaiki critical section yang panjang, deadlock, atau kode interrupt-disabled.

Saya akan menjalankan urutan release yang deterministik dan mencatat block serta unblock H, interval kepemilikan L, interval eksekusi M, dan setiap deadline miss untuk mutex biasa dan mutex PI. Saya juga akan menguji chained donation, multiple waiters, waiter timeout, dan pelepasan bertahap dari multiple locks untuk membuktikan bahwa boosting dan deboosting berjalan dengan benar."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Gambarkan Timeline Unbounded-Inversion untuk Mutex Biasa

Gunakan saat bangunnya H sebagai waktu relatif 0ms. L sudah memiliki lock dan memiliki sisa 3ms pekerjaan CPU:

H menunggu sekitar 23ms dari saat bangun hingga akuisisi mutex, sehingga melewatkan deadline 10ms. Jika task seperti M dapat terus berdatangan saat H terblokir, waktu tunggu H tidak lagi dibatasi oleh sisa 3ms critical section milik L. Itulah yang disebut unbounded inversion di sini. Ini tidak berarti waktu tunggu tak hingga pasti terjadi secara matematis; ini berarti perancangan sistem tidak menyediakan batas blocking yang berhingga dan dapat diaudit yang diturunkan dari sumber daya yang dilindungi.

Bedakan antara deadlock, starvation, dan overload. Deadlock memiliki siklus tunggu di mana tidak ada task yang dapat melepaskan sumber daya yang dibutuhkan. Starvation tidak harus melibatkan pemilik lock. CPU overload biasanya membuat beberapa task melewatkan deadline. Rantai bukti inversi di sini bersifat spesifik: H menunggu sumber daya yang dimiliki oleh L sementara M, yang tidak memiliki dependensi pada sumber daya tersebut, mencegah L untuk dieksekusi.

Langkah 2: Tambahkan Priority Inheritance dan Hitung Ulang

Ketika H terblokir pada 0ms, mutex mendonasikan prioritas waiter tertingginya, yaitu 90, kepada pemilik L. L mempertahankan prioritas dasar 10 dan untuk sementara memiliki prioritas efektif 90:

Kesimpulan 3ms ini bergantung pada asumsi pada prompt: tidak ada task berprioritas lebih tinggi, tidak ada wilayah interrupt-disabled yang panjang, tidak ada bagian non-preemptible, tidak ada page fault, atau I/O yang memblokir, dan mutex benar-benar mengimplementasikan PI. Response time di dunia nyata juga harus mencakup eksekusi H dan semua interferensi berprioritas lebih tinggi. Manfaat utama PI adalah 20ms milik M tidak lagi masuk ke dalam interval pemblokiran sumber daya ini bagi H.

Boosting mengubah prioritas efektif; ini tidak boleh menimpa prioritas dasar L secara permanen. Jika tidak ada donasi lain yang tersisa setelah unlock, L kembali ke 10. Jika waiter berprioritas 80 masih menunggu pada mutex lain yang dimiliki oleh L, L hanya boleh di-deboost ke 80, bukan langsung ke 10.

Langkah 3: Menangani Multiple Waiters, Multiple Locks, dan Rantai PI

Misalkan L memiliki R1 dan R2, H90 menunggu pada R1, dan X70 menunggu pada R2. Prioritas efektif L adalah 90. Setelah L melepaskan R1, H tidak lagi mendonasikan prioritas ke L, tetapi X masih menunggu pada R2, sehingga prioritas L turun ke 70. L kembali ke prioritas dasar 10 hanya setelah melepaskan R2. Timeout atau pembatalan oleh waiter berprioritas tertinggi harus memicu perhitungan ulang yang sama.

Sekarang misalkan L sedang menunggu R3, yang dimiliki oleh K. Hanya menaikkan prioritas L tidak dapat melepaskan lock H karena L sendiri tidak dapat berjalan melewati waktu tunggunya. Prioritas 90 harus dipropagasikan di sepanjang H → R1 → L → R3 → K. K melepaskan R3, memungkinkan L untuk melanjutkan dan akhirnya melepaskan R1. Linux rt-mutex mengelola hal ini dengan set waiter terurut prioritas untuk setiap mutex dan waiter tertinggi dari setiap mutex yang dimiliki dalam set PI waiter milik pemilik.

Chained donation tidak memperbaiki urutan lock yang buruk. Jika L menunggu K sementara K menunggu L, PI hanya menaikkan prioritas task-task dalam siklus tunggu; tidak ada jalur pelepasan yang dapat dieksekusi yang tercipta. Kontrol rekayasa tetap mencakup urutan lock global, pembatasan nesting, tidak ada blocking I/O saat memegang mutex, dan durasi critical section worst-case yang dapat diaudit.

Langkah 4: Bandingkan Priority Inheritance dengan Priority Ceiling

Protokol mutex POSIX memperjelas perbedaan ini:

• PTHREAD_PRIO_INHERIT: pemilik hanya dinaikkan prioritasnya saat ia benar-benar memblokir thread berprioritas lebih tinggi. Prioritas efektifnya menjadi nilai maksimum dari prioritas dasarnya dan donasi waiter yang aktif, dan nested blocking dipropagasikan secara rekursif.
• PTHREAD_PRIO_PROTECT: saat sebuah thread memiliki mutex, thread tersebut dieksekusi setidaknya pada priority ceiling yang dikonfigurasikan untuk mutex tersebut, terlepas dari apakah ada waiter yang sedang menunggu atau tidak.

Inheritance membayar biaya pencatatan runtime dan propagasi rantai ketika terjadi kontensi, tetapi tidak memerlukan pengetahuan di awal mengenai prioritas maksimum setiap pengguna. Ceiling mengharuskan set task/sumber daya diketahui dan dikonfigurasikan dengan benar, sebagai ganti dari batas blocking yang lebih statis dan mudah dianalisis. Apakah protokol ceiling tertentu mencegah kelas deadlock tertentu juga bergantung pada aturan ceiling-admission lengkap di sistem tersebut. Kata "ceiling" saja tidak membuktikan bebas deadlock.

Sketsa inisialisasi POSIX ditampilkan di bawah ini. Kode produksi harus memeriksa dukungan implementasi, return value, hak istimewa scheduling, dan masa pakai mutex:

pthread_mutexattr_t attr;
int rc = pthread_mutexattr_init(&attr);
if (rc == 0) {
  rc = pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT);
}
if (rc == 0) {
  rc = pthread_mutex_init(&bus_mutex, &attr);
}
pthread_mutexattr_destroy(&attr);

Mengatur atribut ini untuk thread biasa SCHED_OTHER di Linux bukanlah jaminan deadline hard real-time. Scheduling class, hak istimewa prioritas real-time, PREEMPT_RT atau perilaku kernel target, dan setiap sumber blocking aplikasi lainnya tetap perlu divalidasi.

Langkah 5: Pilih Primitif yang Tepat dan Perpendek Critical Section

PI bergantung pada pemilik yang pasti. Ketika waiter berprioritas tinggi terblokir, kernel harus mengetahui task mana yang harus dinaikkan prioritasnya. Lindungi shared state dengan mutex pelacak pemilik yang di-unlock oleh pemiliknya. Counting semaphore yang digunakan untuk penghitungan sumber daya atau notifikasi mungkin tidak memiliki pemilik unik, sehingga tidak menyediakan target donasi yang andal. Binary semaphore tidak serta-merta memperoleh semantik PI mutex hanya karena nilainya dibatasi pada nol atau satu.

Bahkan dengan PI, buat critical section dapat dihitung. Salin hanya state yang diperlukan di bawah perlindungan lock. Pindahkan transfer perangkat, logging, alokasi memori, dan pemanggilan fungsi yang dapat sleep ke luar critical section. Untuk akses terserialisasi ke perangkat yang lambat, service task khusus berprioritas tinggi dan message passing mungkin merupakan arsitektur yang lebih baik. Struktur lock-free dapat mengurangi blocking mutex tetapi memperkenalkan reclamation, ABA, retries, dan potensi worst-case execution time yang lebih buruk. Tentukan pilihan berdasarkan analisis deadline, bukan label.

Menaikkan prioritas H tidak dapat menyelesaikan masalah pada prompt ini: H sudah merupakan task tertinggi dan tidak dapat berjalan saat terblokir. Time slice yang lebih pendek hanya menjadwalkan M lebih sering; itu tidak membuat L berprioritas 10 mengungguli M berprioritas 50. Menonaktifkan preemption akan memperbesar latensi respons untuk setiap task dan memindahkan masalah ke dalam wilayah non-preemptible.

Langkah 6: Verifikasi Batas Blocking dengan Trace yang Dapat Direproduksi

Buat urutan release yang pasti: L mengambil lock terlebih dahulu, sebuah barrier mengonfirmasi kepemilikan, H di-release, kemudian M di-release 1ms setelah H terblokir. Jalankan varian mutex biasa, PI, dan priority-ceiling berulang kali lalu catat:

• Distribusi latensi akuisisi mutex H dan jumlah 10ms deadline misses;
• Waktu kumulatif L berstatus runnable tetapi tidak berjalan saat memiliki mutex;
• Interval eksekusi M saat H terblokir;
• Prioritas dasar dan efektif L, pemilik mutex, waiter tertinggi, dan waktu unlock;
• Switch scheduler, wake-up, waktu interrupt-disabled, dan interval non-preemptible.

Trace mutex biasa harus menunjukkan M masuk ke dalam interval tersebut dan H menunggu sekitar 23ms. Pada varian PI, M tidak boleh mem-preempt selama interval di mana H menunggu dan L berstatus runnable saat memiliki mutex; di bawah beban pada prompt, H harus menunggu mendekati 3ms alih-alih 23ms. Tambahkan waiter kedua pada prioritas 70, nested mutex, waiter timeout, dan pelepasan bertahap dari dua lock milik L untuk memverifikasi boost dan deboost terhadap donasi tertinggi saat itu.

Kriteria penerimaan tidak boleh berbunyi "PI berarti tidak ada timeout lagi." Gunakan batas bersyarat: berdasarkan pengukuran critical section maksimum, interferensi prioritas tertinggi, waktu interrupt-disabled maksimum, dan anggaran overhead scheduler, respons worst-case H tetap berada di bawah 10ms, termasuk di bawah kondisi stress dan fault injection.

Contoh Jawaban yang Kuat

"Pertama-tama saya akan menetapkan arah prioritas dan titik awal waktu: 90 adalah yang tertinggi, dan 10ms milik H dimulai saat H bangun. Dengan mutex biasa, H mem-preempt L, mendapati bus_mutex telah dimiliki, dan terblokir. L berjalan kembali selama 1ms, kemudian M berprioritas 50 bangun dan mem-preempt L selama 20ms. L akhirnya mengeksekusi sisa 2ms miliknya dan melakukan unlock. Oleh karena itu, H membutuhkan waktu sekitar 23ms dari bangun hingga akuisisi mutex dan dipastikan melewatkan deadline-nya. M tidak pernah menggunakan mutex tersebut, tetapi secara tidak langsung mencegah H yang berprioritas tertinggi untuk berjalan. Jika pekerjaan berprioritas menengah terus berdatangan, critical section 3ms milik L tidak dapat membatasi pemblokiran ekstra ini.

Dengan PI, H mendonasikan prioritas 90 kepada L saat H terblokir. Prioritas dasar L tetap 10 dan prioritas efektifnya menjadi 90, sehingga M tidak dapat mem-preempt pada 1ms. L menyelesaikan critical section dalam waktu sekitar 3ms dan melepaskan mutex, kemudian H memperolehnya. Oleh karena itu, pemblokiran sumber daya berada di bawah 10ms berdasarkan asumsi pada prompt. Task berprioritas lebih tinggi, waktu interrupt-disabled, dan overhead scheduler dikecualikan dari angka tersebut dan harus diperhitungkan kembali dalam analisis response-time yang nyata.

Implementasi tidak dapat hanya menyimpan satu nilai Boolean status boost. Setiap mutex membutuhkan pemilik dan waiter tertinggi. Setiap pemilik mengambil nilai maksimum dari prioritas dasarnya dan donasi di semua mutex yang dimiliki. Timeout oleh waiter tertinggi atau pelepasan satu lock menyebabkan perhitungan ulang. Jika L terblokir pada lock milik K, prioritas 90 harus dipropagasikan ke K di sepanjang rantai PI. Jika terdapat siklus tunggu, boosting tidak dapat melepaskan sumber daya apa pun, sehingga pemeriksaan urutan lock dan deadlock tetap diperlukan.

Saya akan menggunakan satu urutan release untuk membandingkan mutex biasa dengan mutex PTHREAD_PRIO_INHERIT dan merekam switch scheduler, kepemilikan lock, prioritas efektif, durasi blokir H, dan deadline misses. Bukti kelulusan langsung adalah bahwa M tidak lagi berjalan saat H terblokir dan L yang runnable memegang mutex, serta waktu tunggu H memusat dari sekitar 23ms ke sisa critical section L yang sekitar 3ms ditambah interferensi sistem yang telah diperhitungkan. Waiter kedua, nested locks, timeout, dan unlock satu per satu akan memverifikasi chained boosting dan deboosting yang benar."

Kesalahan Umum

• Hanya mengatakan "task berprioritas rendah memblokir task berprioritas tinggi" → ini mengabaikan bagaimana M mengubah critical section yang berhingga menjadi interferensi yang tak terbatas → gambarkan urutan lengkap: H-blocks, L-runnable, M-preempts.
• Hanya menghitung waktu tunggu 3ms untuk H → ini mengabaikan preemption 20ms oleh M di bawah mutex biasa → ikuti urutan peristiwa hingga sekitar 23ms dan bandingkan dengan 10ms.
• Mengklaim PI menghilangkan setiap priority inversion → H tetap harus menunggu sisa critical section milik L → nyatakan bahwa PI menghilangkan perpanjangan tak terbatas oleh pekerjaan prioritas menengah yang tidak terkait.
• Me-reset L langsung ke 10 setelah satu kali unlock → waiter berprioritas tinggi mungkin masih ada pada mutex lain yang dimiliki → hitung ulang prioritas efektif dari setiap donasi yang masih aktif.
• Hanya menaikkan prioritas pemilik langsung → pemilik yang terblokir pada lock lain tetap tidak dapat berjalan → propagasikan di sepanjang rantai PI serta batasi dan pantau kedalaman rantai.
• Menganggap PI sebagai perbaikan deadlock → task yang dinaikkan prioritasnya dalam siklus tunggu tetap tidak memiliki jalur pelepasan yang dapat dieksekusi → pertahankan urutan lock, kebijakan timeout, dan deteksi deadlock.
• Mengganti mutex dengan binary semaphore sambil berasumsi PI bekerja → semaphore mungkin tidak memiliki pemilik, sehingga tidak ada task yang dapat dinaikkan prioritasnya → gunakan owner mutex yang secara eksplisit mendukung PI untuk perlindungan sumber daya.
• Menganggap PTHREAD_PRIO_INHERIT sebagai sakelar hard-real-time instan → scheduling class, privilege, preemption kernel, interrupt, dan waktu tunggu lainnya tetap memengaruhi deadline → validasi platform secara menyeluruh dan hitung worst-case response time.
• Hanya memeriksa latensi rata-rata yang membaik → jalur deboost, propagasi nested, atau timeout mungkin masih salah → verifikasi tail latency, deadline misses, prioritas efektif, dan batas multiple-lock.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan Lanjutan 1: Mengapa Disebut Unbounded jika M Berjalan Tepat Selama 20ms di Sini?

Latihan ini hanya memuat satu job M, sehingga hasilnya dapat dihitung sekitar 23ms. "Unbounded" menggambarkan mekanisme yang membuat penundaan tambahan tidak memiliki batas berdasarkan critical section milik L. Jika job-job kelas M dapat di-release terus-menerus, L dapat tetap berstatus runnable tanpa mendapatkan CPU dan waktu tunggu H bertambah seiring bertambahnya pekerjaan M. PI menghilangkan interferensi M dari interval blocking ini; batas yang tersisa murni berasal dari critical section dan interferensi berprioritas lebih tinggi.

Pertanyaan Lanjutan 2: Bagaimana Jika H Menunggu L dan L Menunggu K?

Donasikan prioritas 90 milik H ke L, lalu propagasikan melalui mutex tempat L menunggu kepada pemilik K. K mengeksekusi critical section-nya pada prioritas efektif 90 dan melepaskannya, memungkinkan L untuk melanjutkan dan akhirnya melepaskan lock milik H. Sebuah trace harus menunjukkan boost dan deboost terbalik di sepanjang H → mutex1 → L → mutex2 → K. Hanya mengamati boost pada L tidak membuktikan bahwa chained PI sudah benar.

Pertanyaan Lanjutan 3: Prioritas Apa yang Harus Dimiliki L Setelah Waiter Berprioritas Tinggi Mengalami Timeout?

Gunakan permintaan tertinggi yang tersisa. Jika H90 mengalami timeout tetapi X70 masih menunggu pada mutex lain yang dimiliki oleh L, prioritas L turun dari 90 ke 70. L kembali ke prioritas dasar 10 hanya setelah setiap donasi hilang. Penyisipan waiter, keberangkatan, timeout, pembatalan, dan setiap unlock harus mempertahankan state yang terurut berdasarkan prioritas ini.

Pertanyaan Lanjutan 4: Apakah Priority Ceiling Selalu Lebih Baik daripada Inheritance?

Tidak. Ceiling mendukung analisis blocking statis ketika set task dan hubungan akses sumber daya bersifat stabil, tetapi konfigurasi ceiling yang buruk dapat menolak akses yang sah atau membatalkan analisis. Inheritance menaikkan prioritas saat terjadi kontensi aktual dan membutuhkan lebih sedikit konfigurasi di awal, tetapi harus mengelola antrean waiter, propagasi rantai, dan deboosting dinamis. Pilihlah berdasarkan protokol RTOS yang digunakan secara tepat, stabilitas set task, dan overhead runtime yang dapat diterima.

Pertanyaan Lanjutan 5: Mengapa PI Tidak Dapat Memperbaiki I/O Saat Memegang Lock?

Boosting membantu pemilik mendapatkan CPU lebih awal hanya saat task tersebut berstatus runnable. Jika L tertidur (sleep) karena transfer SPI, penyimpanan, page fault, atau peristiwa lain, L akan tetap tertidur. Jika eksekusi berada dalam kondisi interrupt-disabled atau non-preemptible, scheduler juga tidak dapat melakukan intervensi. Pindahkan pekerjaan yang lambat ke luar critical section atau gunakan service task atau protokol asinkron, lalu masukkan waktu penyelesaian hardware terburuk ke dalam anggaran waktu.

Pertanyaan Lanjutan 6: Bagaimana Anda Membuktikan Atribut Tersebut Benar-Benar Berfungsi di User Space Linux?

Periksa return value dari pthread_mutexattr_setprotocol dan pthread_mutex_init, dukungan untuk _POSIX_THREAD_PRIO_INHERIT, kebijakan scheduling aktual dari thread, dan hak istimewa prioritas real-time. Kemudian jalankan beban kerja H/M/L yang terkontrol dan lakukan tracing pada scheduling serta event futex atau lock. Konfirmasikan boost efektif pada L, tidak adanya M dalam interval kritis, dan deboost yang benar setelah unlock atau waiter timeout. Inisialisasi yang sukses atau perbaikan p99 yang terjadi secara kebetulan bukanlah bukti yang cukup.