Jonah#75
"1. Miert nem hasznaljak RTOS-ek alatt a OO nyelveket?
Nem-determinisztikus egy-egy fuggveny lefutasa."
Visszacsatolt rendszerekben SEMMI sem determinisztikus, mert az egész egy nagy állapotgép. Determinisztikus esetekre PLC-t használnak, abban pedig biztosan nem lehet visszacsatolt hálózat, ezzel küszöbölve ki az illegális állapotokat (így nem lesz pl. a stop gombból fordulatszám növelés pl. marógépen).
"2. Miert nem determinisztikus?
Mert szinte ismetlodoen adatszerkezeteken keresztul kell elernie mutatokat melyek eleresi ideje bizonytalan. (proceduralis paradigmat kovetve is vannak ilyen esetek, de a hangsuly szinten a gyakorisagon van)"
adatszerkezetből adatszerkezetbe mutató adat elérési ideje korlátos, ha az elemek száma is korlátos. Az elérési időt csak a programozó határozza meg, legyen az akár VMT, vagy egy sima adattábla, esetleg közvetlen fügvényhívás azáltal, hogy milyen technikát alkalmaz.
"3. Melyek ezek az esetek?
Realtime tipusazonositas. (VMT-t szandekosan nem irom ide mivel futasidoben nem kell foglalkozni az osztalykonzisztenciaval ha a targykodban a metoduscimet tarolod. Ez kizarolag a forditasi idot befolyasolja)"
RTTI működése a fordító kezében van. Minden típushoz hozzárendel egy bizonyos Typeid rekordot, melyben a típus sorszáma szerepel néhány más adat mellet. Ezt az értéket hasonlítja össze a beazonosítani kívánt típus azonosítójával. Ez viszont erősen korlátos futásidejű, C++ esetében 1-2% sebességcsökkenést okoz. sőt, léteznek advanced keresési technikák, ahol többezer adat közül max. 8-10 összehasonlításból megmondható a típusról, hogy megfelelő -e. ha pedig typeid(typespecifier) futásidejét nézzük, akkor annak ideje nagyjából egy órajelciklus, mert ez kb egy define-al egyenértékű művelet. Aztán a VMT-t meg jó is hogy nem írtad le. Mert amit te mondasz, az nem virtuális metódus lesz, hanem static osztály-tagfüggvény, aminek ténylegesen címet tesz bele minden tisztességes C++ fordító az álmoskönyvek szerint is. Virtual tagokra viszont ez nem érvényes, mert ott a VMT tagot az indexe fogja azonosítani (hasonképp mint ahogy egy DLL export függvényeit is azonosítják). Ezen index adat alapján lesz a tagfüggvény megkeresve és meghívva. Mindezt általában cachelik a fordítók a sebesség optimalizálás céljából (amig az objektum-mutató azonos típusra mutat, addig nem is szoktak új VMT keresést indítani). Persze lehet ezt is tárgykódban értelmezni, de sokkal rugalmatlanabbá válik a rendszer, ráadásul a VMT kérdése itt sincs megkerülve: mihelyst átadod az objektumod egy másik osztálynak, máris buktad az osztálytagfüggvény címét. A miértre válasz az öröklődés polimorf mechanizmusa. Ha egy osztálytagföüggvényt felülírunk, akkor annak indexe a régi osztály indexét örökli, de a leszármazottban a régi osztály metódusai még léteznek - mindössze az indexük íródik át (avagy egyes fordítókban egy külön pointer mutat a szülő osztály VMT-jére!).
"4. Miert van erre szukseg?
Hogy garantaljuk a tipusbisztos cimtartomany kezelest."
először is [b[biztos[/b], hogy ezzel még nem lesz típusbiztos a címtartomány kezelésed. A típusbiztosság megköveteli, hogy a forrás és a cél típusa megfeleltethető legyen egymásnak. pl. a C++ eredetileg ilyennek indult, de aztán a C-ből átjött hozadék miatt már nem lett az.
"5. Lehetseges ezt maskent garantalni?
Igen, lehetseges, ha az adatszerkezetek kozti atjarhatosagot kozos protokollokra helyezzuk. Ha autentikus adatszerkezeteket alkalmazunk melyek kozos protokollba (pl. kozos graf adatszerkezetektol fuggetlenul) szervezhetoek akkor globalisan, a teljes rendszerben tetszoleges adat eleresehez szukseges legrosszabb eleresi ido mindig determinalhatova valik. (Az most mas kerdes, hogy sokszor nem csak a legrosszabb eset, hanem ennel joval tobb informacio is determinalhato)"
közös protokolokról nekem az usb jut eszembe. ott egy halom deszkriptor létezik, aminek a kitöltögetése a -közös protokol miatt- jókora erőforrást visz el. Vajon a közös protokolok nem visznek el erőforrásokat úgy, mint pl. egy VMT kezelés ?
Ezen felül az autentikus adatszerkezetek által garantált adatelérési idővel pedig csak óvatosan. Ha nekem olyan az adatom, aminek a kinyerése az adatszerkezetből NP teljes problémát vet fel, akkor a garantálhatóságot dobhatod a kukába.
"Egyebkent a fenti modszerrel az OO alkalmazasokat jellemzo nagy memoriahasznalat is radikalisan csokken ha elunk is a kedvezo lehetosegekkel es eleve ugy epitjuk fel az OS-t, hogy a redundans memoriahasznalatokat mersekelje. (Ugye ha a problemat gyokereiben kezeljuk, varhato hogy mas problemaktol is szabadulunk, amelyeket talan korabban altalanosan el is fogadtunk mellektermekkent es igy mar nem is foglalkoztunk veluk)"
Na persze, és így lesz egy multitask operációs rendszerből multi threaded single task. Ami nagyjából semmit nem ér, mert ad egy nagy pofont az adatbiztonságnak, a szálbiztonságnak, a "közös lónak túros a háta" elvnek, de cserébe garantáltan felvet jópár deadlock problémát, illetve egy halom olyan dolgot, amit még az ellenségemnek és t. családjának sem kívánnék.
Ebből nekem kb. az jön le, hogy lehet olvasott vagy, sokat foglalkoztál vele. De hogy OS-t nem írtál még sem embedded sem PC környezetben az biztos. Amúgy csípem a humorod, legalább értelmesen beszélgetsz:-) Tudod már miért akadt el az OO alapú Linux fejlesztése ? :-))