Programarea aplicatiilor in timp-real Laborator 10 I.

Rularea unei aplicatii client - server pe masina QNX Se considera o aplicatie formata din mai multe procese care trebuie sa se execute pe masina QNX. Pentru executarea acestei aplicatii se urmeaza pasii: 1. Se realizeaza proiectul server si se compileaza (server.c):

2. Se realizeaza proiectul client si se compileaza (client.c):

3. Se deschide fereastra Run. Aici se defineste o noua configuratie C/C++ QNX QConn(IP) pentru masina QNX. In tab-ul Upload se selecteaza directorul unde se vor depune fisierele executabile ale aplicatiei (de exemplu, /home/PATR/grupe/3xx). Acesta va fi directorul de pe sistemul target pe care va se rula aplicatia. De asemenea, se deselecteaza Strip debug information before uploading; Use unique name si Remove upload components after session.

PATR Lab 10

Pag. 1 / 4

4. Se urmeaza aceiasi pasi si pentru aplicatia client.

5. Se realizeaza apoi o configuratie pentru Lauch Group. Se adauga cu Add configuratiile deja realizate in pasul anterior. Pentru aplicatia server se selecteaza un delay de 3 secunde. Dupa ce s-a realizat si aceasta configuratie se lanseaza Run.

PATR Lab 10

Pag. 2 / 4

II. Sincronizarea si comunicatia intre procese prin intermediul zonelor partajate de memorie Mai multe procese pot folosi in comun (partaja) parti ale spatiului de date. Aceasta zona comuna de date se numeste in terminologie QNX obiect de memorie sau fisier mapat1. Obiectul de memorie este o entitate creata in memoria principala, entitate care exista extern procesului care l-a creat. Procesele au acces la aceasta zona de memorie partajata prin intermediul pointerilor. Obiectul de memorie apartine procesului care l-a creat si poate fi accesat de alte procese prin operatia de tip "open". In acest fel, prin functii specifice, spatiul de adresa al procesului va fi extins cu aceasta zona partajata (obiectul de memorie va fi mapat in spatiul de adresa al procesului). Schimbul de informatie prin intermediul zonelor de memorie partajate este cel mai rapid mod de comunicatie intre procese, insa pentru evitarea erorilor sunt necesare mecanisme specifice de sincronizare a accesului la datele continute in obiectul de memorie. Solutia generalizata POSIX este aceea a utilizarii semafoarelor. Pentru crearea si accesarea unui obiect de memorie sunt necesare doua operatii:

alocarea unui descriptor de fisier, fisier pe care alte procese il vor accesa prin nume, cu functia shm_open(); maparea descriptorului intr-o locatie specifica in proces sau intr-o locatie de memorie fizica (de exemplu, pentru a accesa un dispozitiv extern), cu functia mmap().

Alocarea unui obiect de memorie este similara cu operatia de deschidere a unui fisier. In terminologia POSIX, obiectul de memorie devine un fisier mapat. Semafoarele QNX sunt entitati create in memorie, din care cauza procesul care utilizeaza un astfel de semafor pentru accesul la resurse partajate trebuie sa creeze in mod explicit un obiect de memorie pentru a memora structura de tip semafor (sem_t), astfel incat alte programe sa-l poata accesa. Deoarece este posibil ca semaforul sa fie utilizat pentru a controla accesul la o zona de memorie comuna, este util ca si semaforul sa fie plasat tot in zona de memorie, la offset zero (vezi exemplul). Bibliografie: Interfata C/POSIX pentru utilizarea obiectelor de memorie, Programarea Aplicatiilor in Timp-Real, tabelul 3.9, pag. 131. Exemplul 1: Se considera o aplicatie formata din trei procese distincte:

un proces de initializare (Parinte.c), care creeaza doua procese fiu (cu functia spawn()) si un obiect de memorie; doua procese fiu (fiu1.c, fiu2.c), care deschid zona de memorie comuna, o mapeaza in spatiul propriu de adresa si schimba informatie intre ele prin scrieri / citiri din zona comuna de memorie. Se sa realizeze proiectul si sa se ruleze aplicatia.

1 Programarea Aplicatiilor in Timp-Real, pag. 129, sectiunea 3.8.2 PATR Lab 10 Pag. 3 / 4

III.Mecanisme de sincronizare si comunicatie sub QNX / POSIX. Semnale. Nucleul Neutrino pune la dispozitia utilizatorului un mecanism asincron de tratare a evenimentelor numit semnal. Rezultatul normal al primirii unui semnal este acela de terminare a procesului (abort). Pentru a "supravietui" primirii unui semnal, procesul respectiv trebuie sa-si instaleze o rutina speciala de tratare a semnalelor (un handler de semnale). De exemplu, un proces poate dori sa nu fie intrerupt prin Ctrl-C de la tastatura sau poate dori sa dezactiveze toate semnalele atata timp cat executa o sectiune critica de cod. Toate semnalele care sunt dezactivate pe o anumita perioada de timp sunt declarate "pending" si vor fi tratate la reactivare. Spre deosebire de mesaje, semnalele sunt indicatoare complet asincrone ale evenimentelor care apar in sistem. Semnalele mai sunt denumite si intreruperi software, deoarece pot schimba fluxul normal de executie al programului la orice moment de timp si in orice loc al executiei. Exista trei modalitati in care un proces poate primi si trata un semnal: procesul poate trata semnalul prin definirea unei rutine speciale (engl. signal-handler) care sa fie apelata, sa "prinda" semnalul de cate ori acesta este primit si sa execute o anumita actiune specifica, sau procesul poate ignora in mod explicit semnalul (caz in care semnalul este pierdut), nefiind executata nici o actiune, sau procesul accepta semnalul in mod implicit, si se aplica actiunea default in acest caz, actiune care in mod normal presupune terminarea procesului. Exista un numar predefinit de semnale, fiecaruia fiindu-i alocat un numar intreg. Exista, de asemenea, un numar de semnale definite de utilizator ce pot fi folosite in aplicatii. In tabelul sunt prezentate succint cateva dintre cele mai utilizate semnale (QNX dispune atat de semnale care urmeaza standardul POSIX, de semnale specifice QNX, cat si de semnale traditionale UNIX). Bibliografie: Semnale sub QNX, Programarea Aplicatiilor in Timp-Real, capitolul 5, pag. 151. Tratarea semnalelor este posibila in doua moduri: prin instalarea unei rutine de tratare a semnalelor cu ajutorul functiei signal(); prin utilizarea seturilor de semnale (varianta mai complexa, echivalenta POSIX, in care la un moment dat se pot specifica mai multe semnale).

Exemplul 2. Exemplu simplu format din doua procese (ExSemnal.c, ExChild.c), care utilizeaza rutine de tratare de semnal pentru a putea actiona corespunzator la primirea diverselor semnale. Se se ruleze aplicatia. de la alt terminal se trimite un semnal procesului parinte: $ slay -sUSR1 ExSignal Sa se analizeze diverse variante ale rutinei de tratare a semnalelor. De exemplu, ce se intimpla daca nu prindeti CTRL-C in rutina? Sa se explice cazurile analizate.

PATR Lab 10

Pag. 4 / 4