S.O. Temps real: BeOS i QNX

David Escuderos López Pedro López Muñoz S.O. Temps real: BeOS i QNX

S. O. Temps real • Objectius • Com aconseguir-los? • Exemples de S.O. que utilitzen conceptes de temps real.

Objectiu del S.O. en temps real • Donar resposta a un esdeveniment, dins d’un interval de temps determinat. • Aquestes respostes han de ser correctes en el marge de temps requerit, no podem donar resultats parcials. • Hi ha molts tipus de S.O.T.R.: • Dedicats a atendre esdeveniments externs que necessiten respostes. • Dedicats a aplicacions que requereixen execucions en temps real: video, audio, ... • ...

Com aconseguir aquests objectius • La majoria de SOTR es bassa en els següents aspectes: • Gestió de processos: les polítiques de planificació son vitals per aconseguir els objectius proposats. • Gestió de memòria: ha de ser simple per facilitar la velocitat de procés. • Comunicació entre tasques : la comunicació ha de ser el més eficient i ràpida possible (s’utilitzen molt els mailboxes). • Tolerant a fallades : és important que el sistema sigui robust, sobretot si s’utilitza en situacions crítiques. • ...

Exemples de SOTR • BeOS • QNX

Què es BeOS? • S.O. Creat per Be Inc. (Jean-Louis Gasse, 1990) • Fabricat sense tenir en compte compatibilitats amb sistemes anteriors, totalment nou. • 100% gràfic: existeix la possibilitat d’obrir una pantalla de terminal semblant a Unix. • Sistema de fitxers similar a una base de dades relacional. Pot suportar discos de fins 18Terabytes. Es coneix com BeFS (Be File System). • Dissenyat per utilitzar multiprocessadors: actualment fins 8 processadors Intel o PowerPc. • Tot el sistema és orientat a objectes.

Què es BeOS? • Compatible amb la majoria de sistemes de fitxers actuals. • Suport complet de TCP/IP i connectivitat a Internet. • Compatibilitat amb POSIX: malgrat que no es completa. • Dissenyat per treure el màxim partit a aplicacions multimedia : MP3, AVI, ... implementats en el Kernel. Per aquestes aplicacions s’intenta aprofitar el temps real. • Objectius que intenta acomplir : Robust, ràpid, sencill i multimedia.

Com funciona BeOS? • Kernel basat en el concepte client/servidor: Les aplicacions son “clients” que fan peticions al servidor. Per cada tasca BeOS te un servidor especial. • Pas de missatges: La majoria dels objectes permeten la comunicació entre ells, el que fa possible que qualsevol aplicació es pugui comunicar amb qualsevol altre. • Pervasive multithreading: BeOS fa un ús intensiu del concepte multithreading, optimitzant el màxim el temps d’execució. Els programadors poden utilitzar el concepte de thread directament.

Com funciona BeOS? • Protecció de memòria: ofereix protecció a les aplicacions, controla els accessos a memòria i si es detecta que una aplicació accedeix a la memòria d’una altre, la tanca previ avís a l’usuari. • Idea fonamental: amb l’ús de multiprocessadors i el tractament dels threads (planificació en la seva execució), BeOS intenta executar les aplicacions multimedia en temps real.

Threads en BeOS (Blooper Class) • Per realitzar un correcte accés als recursos, ofereix la BLooper class. Cada Blopper controla un determinat objecte i els threads li comuniquen el que volen fer. La Blooper class es necessària ja que si els threads tenen punters comuns, i un destrueix l’objecte al que apunta, tota la resta de threads tindran errors d'accés. S’ha d’indicar al Blooper que l’objecte al que està associat pot rebre missatges de threads. • Amb run(void) la Blooper Class pot crear un thread que escoltarà als processos que volen comunicar-se amb l’objecte.

Threads en BeOS (Blooper Class) • Per comunicar-se: • SendMessage(), SendReply(), PostMessage(). Aquesta última no espera contestació. • El que s’envia son els Bmessage, que es guarden en una cua FIFO. • Una vegada la Blooper Class té el missatge usa els threads associats per realitzar la tasca encomanada. • La Blooper Class només es recomanable usar-la quan tinguem threads que poden compartir punters,... i no es tenen garanties del correcte funcionament.

Threads en BeOS • Creació d’un thread: spawn_thread() retorna un thread_id al pare. • Per començar a executar un thread: resume_thread() : el pare continua executant-se. wait_for_thread() : el pare espera al fill. • Un team és el conjunt de threads que depenen d’un mateix pare (inclòs ell). Comparteixen el mateix espai d’adreces. • Els threads usen memòria virtual, només ocupen espai quan s’executen, i l’alliberen en finalitzar.

Threads en BeOS • Dos tipus de planificació per threads: - real-time. - time-sharing. • Els threads amb real-time, s’executen abans que els time sharing.Si tenim varis real-time es decideix per prioritats. Un thread en real-time s’executa tan aviat com estigui llest.

Threads en BeOS • Prioritats real-time ( per ordre ): - B_REAL_TIME_PRIORITY : latència de 0.5-1 ms. Usat en video i audio en temps real - B_URGENT_PRIORITY : latència de 5-10ms. Per música MIDI. - B_REAL_TIME_DISPLAY_PRIORITY : per controlar accessos de teclat i mouse.

Thread en BeOS La elecció de quin thread s’executarà d’entre els que siguin time sharing, es fa per probabilitat segons la seva prioritat, usant una funció logarítmica en base 2. Per ex.: un thread de prioritat 8 es 4 vegades més possible de ser agafat que un de prioritat 6. Aquests threads tenen un quantum associat i es van executant regularment. La prioritat dels time-sharing són: - B_NORMAL_PRIORITY. - B_DISPLAY_PRIORITY : actualitzar finestres. - B_URGENT_DISPLAY_PRIORITY. - B_LOW_PRIORITY : processos en background.

Threads en BeOS • Altres crides importants: suggest_thread_priority(): el sistema indica quina pot ser la millor prioritat per un thread. suspend_thread(): suspèn l’execució d’un thread fins que es cridi a resume_thread. kill(), kill_team(): per destruir threads. exit_thread(): indica la finalització d’un thread.

Threads en BeOS (Comunicació) • Per escoltar missatges s’utilitza la funció receive_data(). Ens retorna quin thread a enviat el missatge, el tipus de missatge i el missatge. • Per enviar missatges send_data(). Cal especificar el thread destí, el tipus de missatge i el missatge. • Problemes: normalment el que envia no coneix el tamany del buffer de destí de l’altre thread i es poden perdre dades. • En BeOS s’utilitza una alternativa per millorar els problemes d’aquesta comunicació.

Threads en BeOS (comunicació millorada) • S’utilitzen ports (semblants a Mach). • El ports es poden veure com cues FIFO de dades. • Els missatges s’envien a un port del que poden llegir varis threads.

Semàfors • Per realitzar una exclusió mútua cal : • Associar les dades a protegir amb un semàfor amb la comanda create_sem(), que ens retorna l’identificador de semàfor. • Quan un thread vol accedir cal que demani el semàfor amb acquire_sem(). • Per deixar l’exclusió mútua cal usar release_sem(). • Si un altre thread vol accedir a la zona, ha de demanar un acquire_sem(), en aquest cas retornarà un missatge d’error i el thread no podrà entrar. • Pero l’ús de semàfors ens fa perdre temps, en ocasions es triga més temps en demanar i deixar el semàfor que en accedir a les dades. • BeOS té una alternativa: els Benaphore.

Benaphores • En essència es tracta d’usar semàfors, però amb una una variable atòmica associada. • Quan un semàfor vol entrar en una regió crítica, mira el valor de la variable, si és 0 pot entrar, en cas contrari cal esperar. • Quan es vol accedir a la regió automàticament s’augmenta el valor de la variable, així ens indica quants threads volen accedir. • Quan es surt de la regió es decrementa el valor de la variable. • Quan hi ha diversos threads esperant cal usar els semàfors i seguir el conveni anterior, però si un thread arriba i veu que el valor de la variable és 0, pot entrar sense usar semàfors i guanyarem temps.

Resum • BeOS és un sistema en temps real amb l’objectiu de millorar els aspectes multimedia. • Per aconseguir la màxima eficiència aprofita 2 fets fonamentals : • Threads en varis processadors. • Aplicacions trencades en varis threads. • Tot en BeOS es pot executar com threads, de fet una aplicació simple té dos : la finestra i la pròpia aplicació. • Amb tot això veiem que BeOS es capaç d’aconseguir executar de forma satisfactoria aplicacions de video, música, ...

Què es QNX? • Sistema Operatiu en Temps Real comercialitzat per QNX Software System Ltd des de fa 20 anys. • Suport Multiplataforma: x86, MIPS, PowerPC. • Primera versió comercialitzada per PCs en 1981. • Versió 4 Utilitzada en diversos satèl·lits: SAC-C. • Actualment versió Desktop 6.1.0 Per a PCs. • Sistema de finestres gràfic: Photon microGUI • Navegador Web: Voyager TM • Sistema extremadament petit: OS, GUI, browser, servidor, marcador, TCP/IP, etc... en només un disc de 1,44 Mbytes.

Què es QNX? • Proporciona multiprogramació, planificació apropiativa per prioritats. • Suport multiprocessador. • Interfície Estàndard POSIX 1.b. • Implementació Nativa de TCP/IP i connectivitat a Internet. • Canvi de Context extremadament Ràpid: 1,88 µS en Pentium 133MHz; 0,62 µS Motorola G4. • Latència d’interrupció molt petita. • Sistema Operatiu molt petit, dissenyat especialment per a plataformes Embedded. • Objectius que intenta complir: Ràpid, Senzill,Robust, Altament escalable (Telèfons Mòbils fins Servidors).

Què són les plataformes Embedded? • Traducció Literal: aniuat o empotrat. • Arquitectures especialitzades i normalment dedicades. • Generalment dissenyats amb µControlador. • µControlador = µProcessador + Molts Controladors de Perifèrics (Timers, PWM, Controlador d’Interrupcions, A/D, etc.) • Poca quantitat de memòria. • Petit SO en Temps Real emmagatzemat, junt amb el software, en ROMs.

Què són les plataformes Embedded? • Exemples: Computadors d‘Automòbils, Míssils, Maquines Industrials, Sistemes mèdics, Navegadors Web dedicats, dispositius mòbils (Camares Digitals, Telèfons, PDAs), terminals de punt de venda, i fins i tot rentadores, etc... • Tot i ser sistemes dedicats requereixen un petit SO, moltes vegades en Temps Real, per manegar els diferents esdeveniments dels diferents perifèrics. • QNX es ideal per a aquestes plataformes, gràcies als pocs recursos que consum i, especialment, per la grandària del seu nucli, que podria instal·lar-se perfectament en 1Mbyte de ROM.

Com funciona QNX? • QNX aconsegueix la seva eficiència, modularitat i simplicitat, gràcies a: • La seva arquitectura, basada en µKernel. • La comunicació entre processos basat en el pas de missatges. • SO Basat en el µKernel Neutrino. • Neutrino ofereix protecció completa de Memòria: tant per les aplicacions d’usuari com pels components del Sistema (Drivers, Filesystem, etc...)

Com funciona µKernel Neutrino? • Seguint la filosofia µKernel, el SO es veu com un conjunt de processos treballant en grup:

Com funciona µKernel Neutrino? • Neutrino està bastant reduït, i es dedica exclusivament a: • Servei de Thread, seguint l’estàndard POSIX (pthread). • Servei de Signals, seguint ’estàndard POSIX. • Servei de Pas de missatges entre tots el threads i per tot el sistema. • Serveis de Sincronització de Threads, seguint ’estàndard POSIX. • Planificació de Processos/Threads seguint els algoritmes estàndards POSIX per a Temps Real. • Serveis de Temps, seguint l’estàndard POSIX. • Servei de Gestió de Processos, memòria i espai de noms (procnto). • Neutrino mai es planificat! Només s’executa quan es fa una crida a sistema o com a resultat d’una interrupció.

Com funciona µKernel Neutrino? • Tots el serveis del Sistema, excepte procnto (gestió de processos) i els serveis del µKernel, estan implementats a través de processos estàndards: • Manegadors de Sistemes de Fitxers (VFAT, QNX-FS, CDFS, etc.) • Manegadors de Consola, caràcters. • Interfície Gràfica (Photon) • Manegador Natiu de Xarxes • TCP/IP • Etc. • Els controladors de dispositius són també processos estàndard del sistema.

Processos i Threads: • Neutrino implementa totes les crides estàndard de pthreads: creació, destrucció, espera, mutex, variables de condició, atributs, etc. • Moltes d’aquestes crides són traduïdes directament a crides a sistema pròpies de Neutrino (es poden utilitzar els dos models). • A Neutrino, els threads poden tenir 21 estats diferents: CONDVAR, DEAD, INTERRUPT, JOIN, MUTEX, NANOSLEEP, NET_RELPY, NET_SEND, READY, RECEIVE, REPLY, RUNNING, SEM, SEND, SIGSUSPEND, SIGWAITININFO, STACK,STOPPED, WAITPAGE, WAITCTX i WAITTHREAD.

Processos i Threads: • Neutrino pren decisions sobre la planificació dels threads cada vegada que aquests canvien d’estat d’execució. • Els Threads són planificats globalment sense tenir en compte el procés a qui pertanyen. • Neutrino canvia de context cada vegada que el thread: • Es Bloqueja (missatges, semàfors, E/S) • S’encua un thread a la cua de ready d’un procés amb més prioritat. • El thread que s’executa crida a yield();

Processos i Threads: • Cada thread a l’estat READY s’encua amb una prioritat d’execució. • Les prioritats poden anar des de 1 fins a 63 (prioritat més elevada), independentment de la política de planificació. • Sempre s’executa el thread amb més prioritat. • El Gestor de Processos sempre està a la cua de READY amb prioritat = 0. • Per omissió, un thread hereta la prioritat del seu thread creador. • Un thread té dos tipus de prioritat: la prioritat efectiva i la prioritat real. Tot i que habitualment seran les mateixes, la prioritat efectiva podria veure’s afectada per la política de planificació.

Processos i Threads: • Neutrino suporta les polítiques de planificació següents: • FIFO • Round – Robin • Adaptive • Sporadic • Les polítiques són efectives entre threads amb la mateixa prioritat.

Comunicació entre Processos: • QNX es dels primers SO comercials que basa la comunicació entre processos (IPC) principalment en el pas de missatges, que està integrat en el sistema sencer. • Per a QNX, un missatge es un paquet de bytes, que només té sentit pel emissor i receptor (és a dir, no s’inclouen capçaleres). • El pas de missatges s’utilitza també per sincronitzar threads. • Tot i que Neutrino també suporta: Signals i memòria compartida. • I com a processos externs: Cues de Missatges POSIX, Pipes i FIFOs.

Distribució a QNX : • QNX implementa també tots els serveis típics en xarxa: compartició de fitxers, recursos, etc. • QNX va més enllà, i integra tota la xarxa en un únic i homogeni conjunt de recursos. • Un thread d’una màquina pot utilitzar un recurs disponible a qualsevol altre màquina de la xarxa sense haver de distingir si el recurs és local o remot! • Els Usuaris poden accedir a fitxers de tota la xarxa, a dispositius de qualsevol màquina i executar processos a qualsevol node de la xarxa (Permisos)! • A cada Node d’una Xarxa Neutrino se li assigna un nom únic que l’identifica.

RESUM: • Punts Clau: • Suport a nivell del Nucli de threads. • Planificació orientada més a threads que a processos. • Nucli molt reduït. • Politica de Planificació per Prioritats. • BeOS vs. QNX: • BeOS es sistema més aviat orientat a Multimedia. • QNX es sistema més aviat orientat a sistemes embedded, tot i tenir una escalabilitat molt gran.

Bibliografia • Developing Multithreaded Software for the BeOS Kernel Benjamin Stocks, Milwaukee School of Enigneering • http://www.beosfera.com.ar • http://Carlos.zayas.com/beos/artibeos.htm • Documentació Oficial del Sistema. • www.Qnx.com • www.Monografias.com/trabajos6/qnx/qnx.shtml

S.O. Temps real: BeOS i QNX