# Etkileşimli STM32 Mutex ve Priority Inheritance
STM32 / Ders 11
Bu laboratuvar, `priority inversion` sorununu yalnizca bir RTOS terimi olarak degil; `LowTask`, `MediumTask` ve `HighTask` arasinda gercekten hissedilen bir scheduler gerilimi olarak gorunur kilar. Hedef, "neden binary semaphore yetmedi, neden mutex gerekebilir?" sorusunu zaman cizelgesi, gecikme metrikleri ve kilit davranisi uzerinden sezgisel hale getirmektir.
Ne Yap
Kilit politikasini, LowTask kritik bolum suresini, MediumTask CPU patlamasini ve HighTask istek zamanini degistir; ardindan scheduler'in nasil kirildigini ya da toparlandigini izle.
Ne Ogren
`priority inversion`, `binary semaphore`, `mutex`, `priority inheritance` ve `kritik bolum` kavramlarinin neden ayni karar zincirine ait oldugunu gor.
Gorev
Once PI olmayan kilidi dene ve HighTask'in neden bekledigini gor. Sonra ayni senaryoda mutex + PI secerek MediumTask'in nasil devreden ciktigini karsilastir.
Bu konu, "onceligi artir gec" kadar basit degildir. Sorun genellikle paylasilan kaynak, uzun kritik bolum ve yanlis senkronizasyon primitive seciminin ayni anda birikmesinden dogar.
## Bu Derste Ne Oturmali?
1. `Binary semaphore`, karsilikli dislama icin bazen kullanilsa da `priority inheritance` saglamaz; paylasilan kaynak korumasi icin `mutex` genellikle daha dogru secimdir.
2. Yuksek oncelikli task, kaynagi dusuk oncelikli task tutarken bloke olursa; orta oncelikli task araya girip kilidin birakilmasini daha da geciktirebilir. Bu klasik `priority inversion` paternidir.
3. `Priority inheritance`, kilidi tutan dusuk oncelikli task'in efektif onceligini gecici olarak yukselterek mutex'in daha hizli birakilmasina yardim eder.
4. Cozum sadece "RTOS kullan" degil; kritik bolumu kisa tutmak, dogru primitive secmek ve paylasilan kaynagi acikca modellemektir.
```{note}
Bu laboratuvarin sonraki dogal adimi `tickless idle + RTC` olur; onun ardindan `event groups + software timers`, `CAN`, `USB CDC` ya da `RTOS + DMA` entegrasyonu gelebilir.
```