RTOS nedir ?

[mufitsozen]

müfit bey o setup ı bozalı çok oluyor ama VxWorks ile FreeRTOS karşılaştırması biraz abes olur.. wv pasat ile polo yu kıyaslamak gibi olur.. VxWorks ile Integrity falan daha kıyaslanabilir şeyler ama ben o testleri yaparken VxWorks e lisans parası ödemeden halledebilirmiyiz diye araştırıyordum..

dediginde haklisin ama interrupt latency farki %20mi %200mu? RTEMSde baslangicta hard-real-time diye ve ticari bir proje olarak baslamisti, sonradan GPL oldu. Benim bilmek istedigim, VxWorks gibi pahali bir cozum yerine kabul edilebilir bir performansi olan bedava bir cozum.

Neyse setup'i bozduysan yapacak birsey yok, firsat olurda bir stajyer filan bulursam bir denerim.

[Andromeda]

neden? eger butun sistem bu kadarsa bence olur!

rtos u anlamaya çalışıyorum...
verdiğim örnek yanlış mı...

[z]

Bir task bir diger taski fonksiyon cagirir gibi cagirabilirmi?

Cagirabilirse;

Tasklar timer denetiminde sira ile cagrilirken birde fonksiyon cagirir gibi  birbirlerini cagirmaya kalkarlarsa tasklardan bazilarinin hic calisamama (sira gelmeme) gibi bir durumu olusturulabilirmi?

[Andromeda]

öyle hissediyorum ki rtos u algoritmaların içinde aramak boşuna...
rtos  ya pazarlama taktiği yada bir bütünü oluşturan bağımsız çalışan devreler...
yani çok eski bir şey....mesela zil tesisatı...

[Andromeda]

amatör uğraş olarak çok kanallı dimmer asm programı yazmıştım
tam hatırlamıyorum ama 1000 civarında satır vardı sanırım..
sonra picbasic e geçtim...

[z]

task zaten sanal bir kavram ve task a bir giriş noktası olarak bir metod veriyorsunuz zaten (task entry point). Eğer metodunuzda sonsuz döngü yoksa gayet rahat olarak bir task başka task ın "giriş metodu" nu çağırabilir.

benzer şekilde aynı task giriş metodu üzerine birden fazla task da başlatabilirsiniz. bunlar gayet normal şeyler. mesela "thread pool" diye bişii var ki pool da ki task lar (thread ler) aynı task entry point üzerine başlatılır..

Sorumun devami  icin ne soylenebilir?

....fonksiyon cagirir gibi  birbirlerini cagirmaya kalkarlarsa tasklardan bazilarinin hic calisamama (sira gelmeme) gibi bir durumu olusturulabilirmi?

[Andromeda]

konuyu bilmiyorum....
hala anlamaya çalışıyorum...
zil tesisatını onun için örnek verdim...

[Andromeda]

cevap için sağolun....
işin içinde yazılımda var, donanımda..
işe özel yazılım ve donanım oluyor bu rtos...
pc ve programlar bazen çalışmıyor,reset atılıyor, silip tekrar yükleniyor,bir sürü itiş kakış oluyor..... donanımda birşey yok...
sonra çalışıyor...
bütün bunlar rtos olmadığı için yani...

rtos da güvenilir olan yazılım, neden pc de veya windowsda güvenilir değil...?

[Andromeda]

windoze böyle tasarlanmış bir OS değil..

tasarlanamaz mı? ya da neden tasarlanmıyor...

tamam okuyacağım...

[z]

Threadlerin durumlarinin, Run, Ready ve Blocked olarak isimlendirildigini varsayalim.

Thread1 Run durumunda iken, VarA değişkenini Mutex ile koruma altına almış olsun.
Daha işlemi tamamlanmadan Ready konumuna dussun, Thread2 ise Run konumuna gecmis olsun.

Thread2 VarA degiskenine ulasmak istediginde

Bu degiskenin kilit durumunu gosteren, KilitVarA flagini kontrol eden RTOS fonksiyonu cagirir.
Eger VarA kilitli ise RTOS'un mutex fonksiyonu, Thread2 yi otomatik olarak Blocked pozisyonuna iteler. (Yoksa Blocked degil de Ready pozisyonuna mi duser?)

Bu olay anladigim gibi mi cereyan eder?

Thread2 VarA degiskenine ulasmak istediginde bu degiskenin kilitli olup olmadigini test etmeden dogrudan VarA ya ulasmak isterse
sistemin  cuvallamasina neden oluruz.

Dogru mu anlamisim?

Programi biz yazacagimiza gore neleri kilit altina aliyorsak, bunlari kullanacak yazilim parcalarinin her birinde bu kontrolu yapacak fonksiyonu cagirmak bizim sorumlulugumuzdadir. Dogrumudur?

[z]

Aşağıdaki sorunun cevabı hayati derecede önemli.

Bir degişkeni mutex ile kilit altina almış olalım.
Kilidi açmadikca diğer threadler değişkene ulaşamayacaklardır.

Kilidi açma yetkisi kilidi vuran threadde midir? RTOS buna garantor olmaktamıdır?

Yoksa kıllık yapmak istesek diger bir thread kilidi açmak istese açabilirmi?

[mufitsozen]

Aşağıdaki sorunun cevabı hayati derecede önemli.

Bir degişkeni mutex ile kilit altina almış olalım.
Kilidi açmadikca diğer threadler değişkene ulaşamayacaklardır.

Kilidi açma yetkisi kilidi vuran threadde midir? RTOS buna garantor olmaktamıdır?

Yoksa kıllık yapmak istesek diger bir thread kilidi açmak istese açabilirmi?

killik yapmaya gerek yok, programi yazan sizsiniz. Degiskene ulasmak icin mutex'i beklemek zorunda degilsiniz. Beklemezsiniz, degiskenin degeri yanlis olur, programinizdaki hatayi bulmak icin saclarinizi yolarsiniz. Biz profesyoneller buna "bug" diyoruz :-) .

Secim sizin.

[z]

...Eger VarA kilitli ise RTOS'un mutex fonksiyonu, Thread2 yi otomatik olarak Blocked pozisyonuna iteler. (Yoksa Blocked değil de Ready pozisyonuna mi duser?)

Bir parçasını alıntı yaptığım Bir üstteki soruma nasıl cevap veririz?

@Mufitozen hocam.

Elbetteki programı yazan biziz ve bahsettiğim durumda programın sapıtacagı kesin. Kendi çekirdeğini yazmak isteyen neyi impelent edecek neyi etmeyecek belirsiz. RTOS, kilit açma yetkisini sadece kilit vurana vermişse bunu da çekirdeğe implement etmemiz lazım.

[mufitsozen]

Bir parçasını alıntı yaptığım Bir üstteki soruma nasıl cevap veririz?

@Mufitozen hocam.

Elbetteki programı yazan biziz ve bahsettiğim durumda programın sapıtacagı kesin. Kendi çekirdeğini yazmak isteyen neyi impelent edecek neyi etmeyecek belirsiz. RTOS, kilit açma yetkisini sadece kilit vurana vermişse bunu da çekirdeğe implement etmemiz lazım.

Evet, sizinde bahsettiginiz gibi RTOS bunu kontrol edip, bu kontrol mekanizmalarinin tasklar arasinda dogru senkronizasyonu saglamasi lazim. Bundanda daha ileri olarak eger bir deadlock durumu olmus ise, tasklar hep birbirlerini bekliyorlarsa , onuda bir sekilde anlayip, hata vermeli, bunun kaydini tutmali,  sistemi ya restart yada reboot ederek baslatmali yani hata durumundan gracefully cikabilmeli. Cunki sistem basinda kimse olmadanda kendi basina calismaya devam edebilmeli, hatalar olussa bile. Ornegin benim tecrubeli oldugum telekom sistemlerinde bir santralin hic durmadan 20 sene calismasi beklenir. 1 sene boyunca sistemin tamamen hizmet disi kalma suresi 15 dakikayi gecemez. Buna sisteme yeni yazilim yuklenmesi, updateler vb dahildir. (%99.9999 uptime) Herhangi bir trunk hatti eger 10 dakikadan uzun bir muddet hizmet disi kalirsa FCC yazili ve sozlu savunma ister ve genellikle eger mazeretinize inanirsa ve sansiniz varsa 60-100 bin usd bir ceza ile bir daha yapma der. vs. Tabiiki tibbi, askeri sistemler, havacilikta kullanilan sistemler, otomotiv sanayinde kullanilan sistemlerinde bu tip gereksinimleri vardir. Yoksa urununuze satis hakki, yada kullanim lisansi verilmez.

[mufitsozen]

deadlock vs durumlarda sistemin otomatik olarak restart edilmesi vs. çok yanlış olur bence ki öyle yapan bir sistem de var mı bilmiyorum. Onun yerine isteyen watchdog kurup restart edebilir zaten.. bir de sistemde atıyorum 100 task olsun, belki çok önemli olmayan 4-5 task deadlock olacak.. bu durumda diğer tasklar çalışmaya devam edebilirler..

boyle bir suru sistem var, vede kullanimda. Ama seninde dediginde kismen dogru, bu tip error recovery actionlarin vacgecilmez parcalarindan biride watchdog timer routinedir. Tasklarin hepsinin yada calismasi gereken bir kumenin deadlocka girdigini sadece watchdogdan anlamak cok zordur, cunki diyelim 10 task var, 3u deadlocka girmis, diger 7side event bekliyor ve belkide saatlerce schedule edilmeleri gerekmiyecek. Bu arada sistem idle loopta, yada OS icinde calisip duruyor. dolayisi ile watchdog aktif olmayabilir, cunki OS zaten hicbirsey schedule edilmedigi icin watchdog timer'i idle loopta kendisi resetliyordur (hatanin farkina varmazsa) buda sistemin donup kaldigi izlemini verir.


Wikipedia'da soyle bir aciklama var:

Often, neither avoidance nor deadlock prevention may be used. Instead, deadlock detection and process restart are used by employing an algorithm that tracks resource allocation and process states, and rolls back and restarts one or more of the processes in order to remove the deadlock. Detecting a deadlock that has already occurred is easily possible since the resources that each process has locked and/or currently requested are known to the resource scheduler or OS.

ornegin daha once bahsettigim Mars Pathfinder hatasini JPLden bir muhendis soyle aciklamis:

The failure was identified by the spacecraft as a failure of the bc_dist task to complete its execution before the bc_sched task started. The reaction to this by the spacecraft was to reset the computer. This reset reinitializes all of the hardware and software. It also terminates the execution of the current ground commanded activities. No science or engineering data is lost that has already been collected (the data in RAM is recovered so long as power is not lost). However, the remainder of the activities for that day were not accomplished until the next day.

The failure turned out to be a case of priority inversion (how we discovered this and how we fixed it are covered later). The higher priority bc_dist task was blocked by the much lower priority ASI/MET task that was holding a shared resource. The ASI/MET task had acquired this resource and then been preempted by several of the medium priority tasks. When the bc_sched task was activated, to setup the transactions for the next 1553 bus cycle, it detected that the bc_dist task had not completed its execution. The resource that caused this problem was a mutual exclusion semaphore used within the select() mechanism to control access to the list of file descriptors that the select() mechanism was to wait on.

The select mechanism creates a mutual exclusion semaphore to protect the "wait list" of file descriptors for those devices which support select. The vxWorks pipe() mechanism is such a device and the IPC mechanism we used is based on using pipes. The ASI/MET task had called select, which had called pipeIoctl(), which had called selNodeAdd(), which was in the process of giving the mutex semaphore. The ASI/ MET task was preempted and semGive() was not completed. Several medium priority tasks ran until the bc_dist task was activated. The bc_dist task attempted to send the newest ASI/MET data via the IPC mechanism which called pipeWrite(). pipeWrite() blocked, taking the mutex semaphore. More of the medium priority tasks ran, still not allowing the ASI/MET task to run, until the bc_sched task was awakened. At that point, the bc_sched task determined that the bc_dist task had not completed its cycle (a hard deadline in the system) and declared the error that initiated the reset.