Programarea aplicatiilor de timp-real Laborator 1

Tema: Prezentarea sistemului de operare QNX

1.1 Noţiuni teoretice

Sisteme de operare de timp real

Un sistem de timp real se defineste relativ la notiunea de task de timp real. Definim un task ca fiind
o functie individuala care se executa in mod repetitiv in contextul unei anumite aplicatii, astfel incat
aplicatia poate fi descrisa ca o trecere progresiva printr-o secventa de taskuri. La fiecare moment de
timp, aplicatia este implicata in executia unui anumit task, si acest task trebuie planificat.

Task = cea mai mica unitate de prelucrare careia i se atribuie o identitate, reprezentand un program
in forma executabila compus dintr-o succesiune de instructiuni executate secvential.

Cea mai importanta componenta a unui sistem de timp real este sistemul de operare, si in
particular, planificatorul de task-uri. Toate sistemele de operare in timp real trebuie sa ofere trei
functii specifice:

• planificarea taskurilor (engl . Task scheduling ). Planificatorul de task-uri selecteaza (conform

unui anumit algoritm) urmatorul task care va fi lansat in executie;

• task dispatching . Un dispatcher realizeaza operatiile necesare pentru a lansa un task in executie;

• comunicarea intre taskuri .

In general, prin nucleu de timp-real se intelege cea mai mica portiune a unui sistem de operare, care
implementeaza cele trei functii mentionate anterior, insa, din punct de vedere al complexitatii, se
poate considera urmatoarea ierarhizare a "nucleelor":

• nano-kernel : furnizeaza un singur serviciu din cele trei, si anume task dispatching. Face doar
managementul unui singur fir de executie;

• micro-kernel : este un nano-kernel care asigura in plus si planificarea taskurilor;

• kernel : este un micro-kernel care permite in plus sincronizarea cat si comunicatia intre taskuri
prin intermediul semafoarelor, cutiilor postale, etc;

• executiv de timp-real : este un nucleu cu caracteristici mult mai complexe, cum ar fi blocuri de
memorie private, servicii I/O, etc. In aceasta categorie se inscriu cele mai multe nuclee de timp real
comerciale;

• sistem de operare de timp-real: este un executiv care dispune de o interfata utilizator

generalizata, dispozitiv de securitate a datelor, un sistem de gestiune a fisierelor, interfete de retea,
instrumente de depanare etc. In aceasta categorie se inscriu sistemele de operare QNX, Unix, OS-9.

Caracteristicile unui sistem de operare de timp-real:

 planificare preemptiva pe baza de prioritati

 sincronizarea si managementul proceselor
 managementul memoriei
 mecanisme de comunicare intre procese (engl. IPC - Inter Process Communication)
 operatii I/O bazate pe intreruperi
Cerinte pe care trebuie sa la indeplineasca un sistem de operare de timp-real:

 intarzierile introduse de rutinele de tratare a intreruperilor sa fie minime

 comutare rapida de context
 functii de sistem cu semantica simpla care se executa rapid
 timere cu granulatie fina pentru indeplinirea deadline-urilor
 suport retea
 programe de dezvoltare de software (compilatoare, programe de depanare, etc)

Tipuri de sisteme de operare de timp-real:

 nuclee comerciale:
o QNX, OS9, PDOS, pSOS, VxWorks, ERCOS, EMERALDS
o au dimensiuni reduse, functionare multitasking, mecanisme IPC standard (cutii
postale, evenimente, semnale, semafoare), asigura comutare rapida de context
o arhitectura modulara
o ceas de timp-real, planificare pe baza de prioritati, alarme si timeouts.
 extensii ale sistemelor UNIX si ale altor sisteme de operare:
o RT-UNIX, RT-LINUX, RT-MACH,RT-POSIX
o sunt mai lente, mai putin predictibile
o se bazeaza pe un set de interfete standard.
 nuclee experimentale / de cercetare :
o Spring, MARS, HARTOS, MARUTI, ARTS, CHAOS, DARK
o au mecanisme de planificare de timp-real si analiza a comportarii in timp
o pun acces pe predictabilitate, mai putin pe performanta medie
o implementeaza mecanisme de evitare a inversiunii de prioritate (e.g. priority ceiling
protocol)
o asigura suport pentru fault-tolerance si operatii de I/O.

De cele mai multe ori, in sistemele de timp real notiunile de proces si task se refera la acelasi
concept. Un proces este in esenta un cod program care se afla intr-o anumita stare de executie.
Procesul are propriul sau spatiu de adresa si un singur flux de executie (engl. flow of control ).
Contorul program al procesului contine adresa urmatoarei instructiuni care trebuie executata.

Sistemul QNX Neutrino

Sistemul de operare QNX Neutrino este un sistem de operare open bazat pe standardul POSIX API
ce permite dezvoltarea de aplicatii de timp-real, rulabile pe sisteme “ constrained embedded systems”
pana la sisteme de calcul distribuite. El suporta mai multe familii de procesare incluzand INTEL x86,
ARM, XScale, PowerPC, MIPS, and SH-4.

Sistemul de operare QNX este dedicat dezvoltarii aplicatiilor de timp-real, avand facilitati specifice ca
planificarea multitasking preemptiva pe baza de prioritati, posibilitatea comutarii rapide de context,
mecanisme de comunicare intre procese. QNX poate fi utilizat pentru aplicatii stand alone sau pentru
lucrul in retea, fiind extrem de flexibil. Sistemul de operare QNX poate fi "ajustat" in functie de
aplicatie

Sistemul QNX Neutrino ajunge sa asigure un grad ridicat de eficienta, modularitate prin doua
principii de bază:

 Arhitectura microkernel
 Comunicarea interprocese bazată pe mesaje
a. Arhitectura microkernel
Un microkernel al sistemului de operare este structurat ca un mic nucleu ce furnizează servicii
minimale utilizate de procesele ce cooperează. Arhitectura sistemului de operare QNX are la baza
microkernelul Neutrino, care gestioneaza un grup de procese care coopereaza. Microkernelul Neutrino
asigura urmatoarele servicii de baza:

a) servicii asociate firelor de executie. Neutrino furnizeaza primitive pentru crearea firelor de
executie conform standardului POSIX;
b) servicii pentru tratarea semnalelor. Neutrino furnizeaza primitive pentru tratarea semnalelor
conform standardului POSIX;
c) servicii pentru transmiterea mesajelor. Neutrino asigura rutarea tuturor mesajelor intre firele
de executie in intregul sistem;
d) servicii de sincronizare. Neutrino furnizeaza primitive pentru sincronizarea firelor de
executie conform standardului POSIX;
e) servicii de planificare. Neutrino planifica si lanseaza in executie firele de executie utilizand
diversi algoritmi POSIX de planificare in timp-real;
f) servicii pentru gestiunea timpului. Neutrino furnizeaza un set bogat de servicii de timp
conform standardului POSIX;
g) servicii pentru managementul proceselor. Microkernelul Neutrino formeaza impreuna cu
managerul de procese o unitate denumita procnto. Componenta manager de procese
asigura gestiunea proceselor si a memoriei.

Microkernelul Neutrino dispune de apeluri specifice (engl. kernel calls) pentru urmatoarele
facilitati: a) fire de executie; b) transmitere de mesaje; c) semnale; d) ceas (gestiunea timpului); e)
timere; f) rutine de tratare a intreruperilor; g) semafoare; h) lock-uri pentru excludere mutuala
(mutex); i) variabile conditionale (condvars); j) bariere.
Microkernelul Neutrino asigura managementul cooperarii proceselor, actionând ca un fel de
magistrala software ce asigura conectarea dinamică a modulelor de intrare-iesire.

The QNX Neutrino architecture.

Microkernelul QNX reprezinta "inima" sistemului de operare si asigura urmatoarele activitati:
 • comunicarea intre procese . Microkernelul supervizeaza rutarea mesajelor , asigurand
totodata si gestiunea celorlalte doua forme de IPC implementate in cazul QNX, proxies si
semnale ;
 • comunicarea in retea la nivelul de baza . Microkernelul asigura transmiterea mesajelor
destinate proceselor din alte noduri;
  • planificarea proceselor . Planificatorul microkernelului decide care proces se va executa
la momentul imediat urmator;
 • tratarea primara a intreruperilor . Toate intreruperile hardware si erorile sunt transmise
mai intai catre microkernel, care le va transmite apoi driver-ului sau managerului de sistem
corespunzator.

Figura 5 Arhitectura QNX dezvoltata in jurul nucleului Neutrino

Procese sistem. Toate serviciile sistemului de operare sunt furnizate prin intermediul unor
procese standard. Un sistem complet al QNX ar fi:
 filesystem managers
 character device managers
 graphical user interface (Photon)
 native network manager
 TCP/IP

Procese si fire de executie in QNX

Dupa cum s-a mentionat anterior, diferitele sisteme de operare dau adeseori intelesuri diferite unor
termeni ca "proces", "fir de executie", "task", "program", etc. In QNX se folosesc in mod tipic doar
termenii "proces" si "fir de executie". O "aplicatie" inseamna in mod tipic o colectie de procese, iar
termenul "program" este in mod uzual echivalent cu "proces".

Un fir de executie reprezinta un singur flux de executie sau control. Prin intermediul firelor de
executie este posibila o gestiune diferita a spatiului de adresa alocat unui proces (figura 3). Spatiile
de cod, date si memorie disponibila sunt aceleasi pentru toate firele de executie care apartin
aceluiasi proces. Comunicatia între firele de executie se face prin zonele comune de memorie.
Fiecare fir de executie are starea lui. Comutarea firelor de executie este mult mai simpla (se
salveaza câtiva registri ai procesului si stiva) si rapida.

Un proces este in esenta un cod program care se afla într-o anumita stare de executie. Procesul are
propriul sau spatiu de adresa (figura 4) si un singur flux de executie (engl. flow of control ).
Contorul program al procesului contine adresa urmatoarei instructiuni care trebuie executata.

Dezvoltarea unei aplicatii concurente sub QNX se realizeaza utilizand modelul firelor de executie
conform standardului POSIX. In functie de natura aplicatiei, firele de executie se pot executa
independent, fara comunicare intre algoritmi, sau pot fi strans legate, necesitand comunicare si
sincronizare. Un proces va contine intotdeauna cel putin un fir de executie. In functie de natura
aplicatiei, microkernelul Neutrino si managerul de procese pot fi configurate astfel incat sa permita
executia unei combinatii de fire de executie si procese (conform standardului POSIX).

Gestiunea firelor de executie sub QNX

Atributele firelor de executie

Firele de executie dintr-un proces impart datele comune din spatiul de adresa al procesului. Fiecare
fir de executie beneficiaza si de anumite date private. Unele dintre aceste date sunt protejate de
nucleu (de exemplu, identificatorul firului de executie, tid ), altele putand exista neprotejate in
spatiul de adresa al procesului (de exemplu, stiva asociata fiecarui fir de executie). Urmatoarele
resurse asociate firelor de executie sunt private:

Tabelul 5-1 Resurse private asociate firelor de executie

Nume Semnificatie
Tid Fiecare fir de executie este identificat printr-un numar unic, incepand cu
valoarea 1. Numarul tid este unic in procesul care contine firul de
executie respectiv.
Setul de registri Fiecare fir de executie are propriul contor program, pointer se stiva,
precum si alti registri - procesor specifice.
Stiva Fiecare fir de executie se executa in propria stiva, memorata in spatiul de
adresa al procesului.
Masca de semnal Fiecare fir de executie are propria sa masca de semnal.
Zona locala de Fiecare fir de executie dispune de o zona de date denumita "thread local
memorare storage" (TLS). Zona TLS este utilizata pentru a mentine informatie
referitoare la firul de executie respectiv (de exemplu, tid , pid , baza
stivei, alte date specifice). Nu va fi accesata direct de aplicatia
utilizatorului.

Datele specifice firelor de executie, implementate in biblioteca pthread si memorate in TLS,

furnizeaza un mecanism prin care se asociaza o valoare (cheie) intreaga globala a procesului cu o
valoare unica asociata firului de executie.

Starile posibile ale firelor de executie

Firele de executie pot fi create si distruse in mod dinamic in cadrul unui proces. La crearea unui fir
de executie (cu ajutorul functiei de biblioteca pthread_create() ) se aloca si se initializeaza resursele
necesare in spatiul de adresa al procesului. Terminarea executiei firului de executie (cu functii
specifice de biblioteca pthread_exit() , pthread_cancel() ) implica oprirea firului de executie si
eliberarea resurselor alocate acestuia. Pe durata existentei sale, un fir de executie se poate afla in
una dintre urmatoarele stari:

Tabelul 5-2 Starile posibile ale firelor de executie in QNX

Starea Semnificatie
CONDVAR Firul de executie este blocat pe o variabila conditie (i.e. a facut
pthread_condvar_wait() )
DEAD Firul de executie s-a terminat si asteapta un join din alt fir de
executie.
INTERRUPT Firul de executie este blocat in asteptare pe o intrerupere (i.e. a
facut InterruptWait() ).
JOIN Firul de executie este blocat asteptand sa faca join cu un alt fir de
executie (i.e. a cerut pthread_join() ).
MUTEX Firul de executie este blocat pe un mutual exclusion lock (i.e. a
facut pthread_mutex_lock() ).
NANOSLEEP Firul de executie este in sleep pentru un scurt interval de timp (i.e.
a facut nanosleep() ).
NET_REPLY Firul de executie asteapta un mesaj de raspuns din retea (i.e. a facut
MsgReply*() ).
NET_SEND Firul de executie asteapta un semnal ce va fi transmis in retea (i.e. a
 facut MsgSendPulse() , MsgDeliverEvent() , sau SignalKill() ).
READY Firul de executie asteapta sa se intre in executie, timp in care
(gata de executie) procesorul executa un alt fir cu prioritate mai mare sau egala.
RECEIVE Firul de executie este blocat in asteptarea unui mesaj (i.e. a facut
MsgReceive() ).
REPLY Firul de executie este blocat pe message reply (i.e. a facut
MsgSend() si serverul a receptionat mesajul).
RUNNING Firul de executie se executa.
SEM Firul de executie asteapta sa se semnalizeze pe un semafor (i.e. a
facut SyncSemWait() ).
SEND Firul de executie este blocat pe message send (i.e. a facut
MsgSend() , insa serverul nu a primit inca mesajul).
SIGSUSPEND Firul de executie este blocat in asteptarea unui semnal (i.e. a facut
sigsuspend() ).
SIGWAITINFO Firul de executie este blocat in asteptarea unui semnal (i.e. a facut
sigwaitinfo() ).
STACK Firul de executie asteapta alocarea unui spatiu de adresa virtual
pentru stiva (i.e. parintele sau a facut ThreadCreate() ).
STOPPED Firul de executie este blocat in asteptarea unui semnal SIGCONT.
WAITCTX Firul de executie este blocat in asteptarea unei valori reale.
WAITPAGE Firul de executie asteapta alocarea memoriei fizice pentru o adresa
virtuala.
WAITTHREAD Firul de executie asteapta sa fie creat un fir de executie "child" (i.e.
a facut ThreadCreate() ).

Dupa cum se observa in tabelul 5-2, sistemul de operare QNX permite comunicarea intre procese (si
intre fire de executie) prin intermediul mesajelor, utilizand primitive de tipul send() (pentru
transmiterea mesajelor), receive() (pentru receptionarea mesajelor), reply() (pentru transmiterea
raspunsului la un mesaj). Deoarece aceste primitive sunt cu blocare, se face implicit si o
sincronizare intre procesele (firele de executie) care le apeleaza. Astfel, procesele (firele de
executie) sunt blocate atunci cand asteapta ca o anumita parte a unui protocol de transmitere de
mesaje sa se incheie (tabelul 5-3).

Tabelul 5-3 Schimbarea starii firelor de executie prin transmiterea mesajelor

Daca procesul a facut … … procesul intra in starea …
Send() si mesajul transmis nu a fost SEND - blocked
receptionat de receiver …
Send() si mesajul a fost receptionat, dar REPLY - blocked
receiver-ul nu a raspuns inca …
receive() dar nu a primit inca mesajul … RECEIVE - blocked

Fiecarui fir de executie ii este asociata o prioritate. Pentru a selecta urmatorul fir de executie care
va intra in executie planificatorul va analiza prioritatea thread-urilor care sunt in stare READY (gata
de executie). Thread-ul cu prioritatea cea mai mare va fi lansat in executie. Prioritatea firelor de
executie (figura 6) poate varia intre 1 (minim) si 63 (maxim), independent de algoritmul de
planificare. Exista un thread special idle (managerul de procese) a carui prioritate este 0, care este
intotdeauna in stare gata de executie. Un fir de executie mosteneste prioritatea "parintelui" sau.

Firele de executie sunt ordonate in coada READY in functie de prioritate. Coada READY este
implementata sub forma a 64 de cozi separate, cate una pentru fiecare prioritate. Firele de executie
sunt inserate in coada corespunzatoare prioritatii proprii in ordine FIFO. Pentru executie este
selectat thread-ul cu prioritatea cea mai mare.

Planificarea firelor de executie

Executia unui fir de executie este suspendata temporar la executia unui apel de sistem, la tratarea
unei exceptii sau a unei intreruperi hardware. Modificarea starii unui fir de executie conduce la o
noua decizie de planificare. In mod normal, un fir de executie isi va relua executia din punctul in
care a fost intrerupt, planificatorul realizand o comutare de context intre firele de executie atunci
cand firul de executie care se executa in mod curent:

• se blocheaza (atunci cand trebuie sa astepte aparitia unui eveniment, e.g. raspunsul la o cerere
IPC, asteptare pe un mutex, etc). Firul de executie blocat este scos din coada de procese gata de
executie (ready) si este lansat in executie (intra in starea running) firul de executie cu prioritatea cea
mai mare din coada ready. Atunci cand firul de executie este deblocat, este reinserat la sfarsitul
cozii ready pentru nivelul corespunzator de prioritate;

• este scos din executie in mod preemptiv de un fir de executie cu prioritate mai mare. Firul de
executie care se executa in mod curent va putea fi scos din executie atunci cand un alt thread cu
prioritate mai mare este pus in coada READY, ca rezultat al expirarii conditiei sale de blocare.
Thread-ul scos preemptiv din executie va fi pus la inceputul cozii READY la nivelul de prioritate
corespunzator;

• yields. Firul de executie elibereaza procesorul in mod voluntar (prin sched_yield() ) si este plasat
la sfarsitul cozii READY la prioritatea corespunzatoare. Se va executa astfel firul de executie cu
prioritatea cea mai mare).

Sistemul de operare in timp-real QNX dispune de mai multi algoritmi de planificare, si anume
planificare de tip FIFO, planificare de tip round-robin, planificare adaptiva si planificare sporadica.

I. Comenzi uzuale
Afisarea numelui directorului de lucru $ pwd
Schimbarea directorului de lucru
$ cd
Listare continut director curent
$ ls
Afiseaza calea pina la un anumit fisier (de $ which ls

exemplu, comanda ls2)

Help si optiunilor de executie ale unei comenzi $ use cmdname
3
Stergerea unui fisier din linia de comanda $ rm fisier
Copierea unui fisier din linia de comanda $ cp sursa destinatie
Muta sau redenumeste fisiere din linia de $ mv
comanda
Cauta un fisier din linia de comanda $ find fisier
Creaza un director din linia de comanda $ mkdir nume_director
Sterge un director din linia de comanda $ rmdir nume_director
Accesul la o discheta format MS-DOS. $ mount -tdos /dev/fd0
Discheta se acceseaza apoi prin intermediul
File Manager4. In mod analog se instaleaza un /fs/floppy
CD. Redirectari5:
• redirectare rezultat comanda
•
programul preia intrarea dintr-un fisier, in $ ls *.c > temp
loc de la tastatura
$ my_prog <
• adauga iesirea comenzii la sfirsitul
fisierului file; daca nu exista, il creeaza si file
apoi scrie in el
• listeaza fisierul sursa C in alt fisier (files) si
mesajele de eroare le trimite in fisierul
errors
Afisare drepturi de acces la fisiere
Schimbarea drepturilor de acces la directoare
/fisiere:
• da drept de executie pentru oricine asupra $ chmod +x file

$ cmd >> file

$ ls cici.c > files >

errors

$ umask
1
Rezultatul comenzii este de forma urmatoare:
tip owner group other links owner group octeti data_ultima_modificare nume

d rwx rwx r-x 4 frank user 4096 Jan 12 09:53 hello.c

2
Programele executabile si comenzile se afla in directoarele /bin si /usr/bin
3
Toate aceste comenzi pot fi executate si prin intermediul interfetei grafice Photon, din utilitarul
File Manager
4
In directorul /dev se afla descriptorii pentru dispozitive de memorare externa: hard-disk (hd0-
dos), discheta (fd0),
CD-ROM, etc.
5
Sunt valabile urmatoarele redirectari:
< file citeste standard input (0) din fisierul file
> file scrie standard output (2) in file
>> file ataseaza standard output (2) la sfirsitul fisierului file
<< s citeste de la standard input (0) pina cind apare o linie care contine doar sirul s
c1|c2 pipe - trimite standard ouput a procesului c1 la standard input a procesului c2
2
 fisierului file
• suprima dreptul de executie $ chmod -x file
1
• da drept de executie ownerului si grupului $ chmod u+x,g+x file
sau asupra fisierului file
Definirea unui alias pentru o comanda. Alias-ul $ alias dir=’ls -l’
trebuie definit in fisierul .profile care se afla in
directorul de login2.
Gasirea variabilelor de mediu
$ echo $PATH
Setarea unei noi cai
$ PATH = newpath
Adaugarea unui director la calea curenta
$
Compilarea programelor PATH=$PATH:/usr/local/b
• compilare in fisier executabil a.out in
• compilare in fisier executabil hello.out
• compilare in background; se accepta alta $ qcc ./hello.c
comanda
• comanda de compilare se executa in $ qcc ./hello.c -o
background, chiar daca utilizatorul face
logout. Iesirea programului si mesajele de
eroare sunt redirectate in mod automat intr- hello.out
un fisier nohup.out
Forteaza executia unui fisier executabil din $ qcc ./test.c &
directorul curent
Afisarea informatiei despre starea sistemului, $ nohup qcc ./test.c &
grafic, in fereastra Photon3
Afisarea informatiei despre starea sistemului, in
mod text, in ferestra Terminal
Terminarea fortata a unui proces prin trimiterea $ ./hello.out

$ psin

$ sin

$ kill pid
1
Pentru specificarea drepturilor de acces se foloseste urmatoarea notatie:
Clasa u user g grup o all other users a all
Operatori + add - remove = replace
Permisiune r read w write x execute

Drepturile de acces pot fi specificate si octal:

chmod 0 file suprima toate drepturile de
chmod 777 acces seteaza toate drepturile
file chmod de acces seteaza read pentru
440 file user si grup seteaza write
chmod 2 file pentru others
Directorul de login este directorul in care este directionat utilizatorul dupa verificarea parolei.
Fisierul .profile se executa dupa fiecare operare de login realizata in mod corect. Fisierul .profile se
executa din linia de comanda cu comanda:
$ . .profile
3
Acelasi rezultat de obtine accesand meniul Launch/Utilities/System Information. Se deschide
fereastra System Process Inspector, in care sunt disponibile informatii despre procesele care
ruleaza in sistem (Name, Pid, Code, Data, Stack, CPU), respectiv informatii despre firele de
executie asociate fiecarui proces (Tid, Priority, State, Blocked, IP, CPU).
3
 unui semnal SIGTERM. Pid este ID-ul
procesului, si poate fi obtinut din fereastra
System Process Inspector.

Crearea proceselor si firelor de executie in QNX

Diferitele sisteme de operare dau adeseori intelesuri diferite unor termeni ca "proces", "fir
de executie", "task", "program", etc. In QNX se folosesc in mod tipic doar termenii "proces" si
"fir de executie". O "aplicatie" inseamna in mod tipic o colectie de procese, iar termenul
"program" este in mod uzual echivalent cu "proces". Un proces va contine intotdeauna cel putin
un fir de executie.

In functie de natura aplicatiei, microkernelul Neutrino si managerul de procese pot fi

configurate astfel incat sa permita executia unei combinatii de fire de executie si procese
(conform standardului POSIX).