Sincronizare, Arhitecturi de Kernel și RTOS-uri pentru Sisteme Embedded

1Obiectul și structura cursului6 min

Un task planificat corect, dar care corupe datele altui task, nu e un sistem funcțional - e un sistem care eșuează imprevizibil. Sincronizarea corectă a accesului la resurse partajate e la fel de esențială ca planificarea temporală studiată în Cursul 07, iar cele două probleme sunt legate mai strâns decât pare la prima vedere: un mecanism de sincronizare prost ales poate distruge garanțiile de schedulabilitate demonstrate anterior.

Rezultate ale învățării

• Să identificați o condiție de cursă și să explicați de ce apare la o operație aparent simplă
• Să alegeți între mutex, semafor și grup de evenimente pentru un scenariu dat
• Să explicați inversiunea de prioritate și să aplicați Priority Inheritance sau Priority Ceiling
• Să comparați arhitectura monolitică cu microkernel din perspectiva izolării erorilor
• Să descrieți rolul MPU/MMU și diferența dintre AMP și SMP pe platforme multicore
• Să enumerați criteriile practice pentru alegerea unui RTOS într-un proiect real

2Condiții de cursă și secțiuni critice8 min

Chiar și o operație care arată atomică în cod poate fi, la nivel de procesor, o secvență de trei pași separați:

uint32_t event_count = 0;
void TaskA() { ++event_count; }
void TaskB() { ++event_count; }

event_count++ nu e neapărat o singură instrucțiune: se descompune în citirea valorii din memorie, incrementarea ei și scrierea rezultatului înapoi. Dacă TaskA și TaskB execută această secvență aproape simultan, se poate întâmpla:

O secțiune critică trebuie să fie cât mai scurtă: fără operații blocante, fără întârzieri voluntare, fără calcule care pot fi mutate în afara ei.

// Varianta A - secțiune critică excesiv de lungă
lock(data_mutex);
read_shared_data();
perform_complex_filtering();
write_external_flash();
send_network_packet();
unlock(data_mutex);

// Varianta B - copiere rapidă, procesare în afara mutex-ului
SensorData local_copy{};
lock(data_mutex);
local_copy = shared_sensor_data;
unlock(data_mutex);
perform_complex_filtering(local_copy);
write_external_flash(local_copy);
send_network_packet(local_copy);

3Mutex-uri și semafoare10 min

Trei primitive de sincronizare acoperă majoritatea nevoilor unui sistem embedded: mutex-ul, semaforul și grupul de evenimente.

// Mutex - protejarea unei resurse partajate, cu timeout
if (lock_mutex(configuration_mutex, mutex_timeout)) {
    shared_configuration = new_configuration;
    unlock_mutex(configuration_mutex);
} else {
    handle_lock_timeout();
}

// în ISR
void ADC_IRQHandler() {
    read_conversion_result();
    give_semaphore_from_isr(adc_ready_semaphore);
}

// în task
void ProcessingTask() {
    while (true) {
        take_semaphore(adc_ready_semaphore, portMAX_DELAY);
        process_adc_sample();
    }
}

4Grupuri de evenimente și cozi de mesaje6 min

Grupurile de evenimente permit unui task să aștepte o combinație logică de condiții, nu doar una singură:

Cozile de mesaje transportă date, nu doar semnalizare - un task „pune" un element, altul „scoate", cu blocare (și timeout) la coadă plină sau goală. Un aspect ușor de neglijat: proprietatea datelor transmise printr-o coadă trebuie definită explicit - odată ce un buffer a fost transmis, task-ul emițător nu ar trebui să-l mai modifice, altfel apare, din nou, o condiție de cursă, doar mutată de la o variabilă globală la un obiect transmis prin canal.

• „Am folosit o coadă de mesaje, deci sunt protejat de condiții de cursă." Doar dacă și proprietatea datelor e respectată strict - dacă emițătorul continuă să scrie în bufferul transmis după ce l-a pus în coadă, problema revine sub altă formă. Transferați proprietatea complet: după trimitere, emițătorul nu mai atinge acel buffer.

5Inversiunea de prioritate8 min

Cele trei primitive de mai sus rezolvă corectitudinea accesului la date - dar introduc o problemă nouă, pur temporală, când task-uri cu priorități diferite partajează aceeași resursă.

Trei task-uri: τH (prioritate mare), τM (prioritate medie), τL (prioritate mică). τL deține un mutex M. Scenariul problematic:

1. τL obține mutex-ul M și intră în secțiunea critică.
2. τH devine Ready, preemptează pe τL, dar apoi solicită și el mutex-ul M → τH se blochează, așteptând ca τL să-l elibereze.
3. τM devine Ready. Cum τL are prioritate mai mică decât τM, τM preemptează pe τL.
4. τM rulează cât are nevoie, fără să folosească deloc mutex-ul M - dar, cât timp τM rulează, τL nu poate finaliza secțiunea critică, deci nu poate elibera M, deci τH rămâne blocat.

Soluția nu e „evitați mutex-urile" - e să limitați explicit cât poate dura blocarea, prin protocoale dedicate de control al priorității, subiectul următoarelor două secțiuni.

6Priority Inheritance Protocol8 min

Priority Inheritance Protocol (PIP) reduce inversarea de prioritate prin ridicarea temporară a priorității task-ului care deține resursa.

Aplicat scenariului anterior:

1. τL deține mutex-ul.
2. τH solicită mutex-ul și se blochează.
3. τL moștenește prioritatea lui τH.
4. τM nu mai poate preempta pe τL, pentru că prioritatea efectivă a lui τL e acum mai mare decât a lui τM.
5. τL termină rapid secțiunea critică și eliberează mutex-ul.
6. τH e deblocat și rulează.
7. τL revine la prioritatea sa de bază.

Blocarea lui τH e acum mărginită de durata secțiunii critice a lui τL, nu de interferența unui număr nedeterminat de task-uri intermediare.

De asemenea, în multe RTOS-uri, Priority Inheritance e implementat pentru mutex-uri, nu pentru semafoare binare - înlocuirea unui mutex cu un semafor, într-un cod care pare echivalent, poate elimina complet protecția împotriva inversiunii de prioritate, fără niciun avertisment.

7Priority Ceiling și reguli de proiectare10 min

Protocoalele de tip Priority Ceiling atribuie fiecărei resurse o valoare numită plafon de prioritate (priority ceiling).

Există mai multe variante. În Immediate Ceiling Priority Protocol (varianta cea mai folosită practic), task-ul care obține o resursă primește imediat prioritatea plafonului acelei resurse:

Alegerea între Priority Inheritance și Priority Ceiling depinde de serviciile oferite de RTOS, posibilitatea cunoașterii anticipate a tuturor utilizatorilor unei resurse, cerințele de analiză formală și nivelul de criticitate al sistemului - Priority Ceiling e mai potrivit pentru sisteme statice, bine analizate dinainte; poate fi dificil de aplicat în arhitecturi foarte dinamice, unde nu se cunosc dinainte toți utilizatorii posibili ai unei resurse.

8Arhitecturi de kernel: monolitic vs. microkernel10 min

Arhitectura kernelului stabilește distribuția responsabilităților între codul privilegiat și componentele aplicației - o decizie care influențează latența serviciilor, costul comunicației între componente, izolarea erorilor, suprafața de cod cu privilegii, și posibilitatea certificării.

Arhitectura cu spațiu unic (monolitică)

Kernelul, driverele și aplicația accesează aceeași memorie, legate frecvent într-o singură imagine executabilă: Aplicație + servicii + kernel + drivere → imagine firmware. Un apel de serviciu e, de regulă, direct: C_serviciu ≈ C_apel + C_kernel, fără schimbare de spațiu de adrese și fără copiere de mesaje.

Avantaje: latență redusă, overhead mic, utilizare eficientă a memoriei, integrare simplă pe microcontrolere fără MMU. Limitare principală: propagarea erorilor - un pointer invalid dintr-un driver poate modifica memoria kernelului sau stiva altui task, pentru că nu există o graniță hardware între ele.

Microkernel și servicii separate

Un microkernel păstrează în modul privilegiat numai mecanismele esențiale: planificarea, gestionarea firelor, comunicația inter-proces (IPC), spațiile de adrese, întreruperile și controlul accesului la resurse. Driverele, sistemele de fișiere și stivele de rețea rulează în componente separate, accesate prin schimb de mesaje: client → IPC → server, cu un cost suplimentar față de apelul direct:

Beneficiul: dacă un driver neprivilegiat eșuează, kernelul poate împiedica accesul lui la memoria altor componente, iar sistemul poate opri driverul, reporni serviciul sau trece într-un mod degradat - fără să compromită restul sistemului.

9Protecția memoriei: MPU și MMU8 min

Izolarea software descrisă mai sus necesită suport hardware. Două componente centrale sunt MPU (Memory Protection Unit) și MMU (Memory Management Unit).

MMU-ul adaugă, suplimentar, traducerea adreselor virtuale în adrese fizice: A_fizic = M(A_virtual) - permite spații de adrese separate și paginare, cu un cost hardware și software mai mare decât un simplu MPU.

Într-un sistem cu MPU, un task neprivilegiat poate avea acces la propria stivă, datele proprii, un buffer partajat explicit și anumite periferice - dar nu la memoria altui task sau a kernelului. O încercare de acces în afara regiunilor permise generează o excepție, iar handlerul de eroare poate identifica task-ul vinovat, adresa accesată și tipul operației.

10Multicore și sisteme cu criticitate mixtă10 min

Procesoarele embedded moderne conțin, tot mai frecvent, mai multe nuclee. Două modele principale de organizare: AMP (Asymmetric Multiprocessing) și SMP (Symmetric Multiprocessing).

AMP oferă o separare arhitecturală mai clară, cu comunicare explicită între nuclee prin memorie partajată, mailbox-uri hardware sau întreruperi inter-core. SMP permite utilizarea flexibilă a nucleelor, dar introduce complexități noi: execuție paralelă reală, migrarea task-urilor între nuclee, lock-uri între nuclee, interferență asupra cache-ului comun și dificultăți suplimentare în analiza WCET.

Sisteme cu criticitate mixtă

Într-un sistem cu criticitate mixtă, funcții cu niveluri diferite de importanță (de exemplu control critic și interfață grafică; funcție de siguranță și conectivitate) folosesc aceeași platformă hardware. Separarea trebuie realizată atât spațial, cât și temporal:

Un sistem cu criticitate mixtă poate trece într-un mod de criticitate ridicată atunci când timpul de execuție al unei funcții critice depășește estimarea normală - în acel mod, activitățile necritice pot fi reduse sau suspendate pentru a păstra funcțiile esențiale, exact ca o formă de degradare controlată la suprasarcină.

11RTOS-uri moderne: o privire comparativă10 min

Ecosistemul de sisteme de operare embedded acoperă un spectru larg: kerneluri compacte pentru microcontrolere, sisteme apropiate de POSIX, platforme Linux cu preempție în timp real și microkerneluri cu izolare formal verificată.

FreeRTOS oferă task-uri, priorități, planificare preemptivă sau cooperativă, cozi, semafoare, mutex-uri și grupuri de evenimente - exact primitivele studiate în această lecție - într-o imagine statică, legată direct cu aplicația. Zephyr separă descrierea hardware-ului (Devicetree) de logica aplicației, permițând aceleiași aplicații să ruleze pe platforme diferite. NuttX apropie dezvoltarea embedded de modelul POSIX clasic (pthread_create, descriptori de fișiere, socket-uri). Linux cu PREEMPT_RT reduce regiunile nepreemptibile din kernel, dar rămâne potrivit doar pentru platforme cu procesor performant, MMU și memorie suficientă - și, ca peste tot în acest domeniu, utilizarea PREEMPT_RT nu demonstrează, singură, respectarea unui deadline; platforma trebuie măsurată în configurația reală a produsului.

12Criterii de alegere a unui RTOS8 min

Nu există un RTOS universal optim. Selecția trebuie să pornească de la cerințele sistemului, nu de la popularitatea unei tehnologii, și trebuie să răspundă la o singură întrebare centrală:

Criteriile trebuie ponderate diferit în funcție de context: pentru un dispozitiv simplu, memoria și costul pot domina decizia; pentru un sistem critic, izolarea, certificarea și predictibilitatea temporală au, de regulă, prioritate.

Un certificat de siguranță e relevant numai dacă versiunea folosită e cea acoperită de el, configurația e permisă, iar procesorul și compilatorul sunt cele suportate - un pachet de certificare pentru o versiune diferită de RTOS nu se transferă automat.

Procesul recomandat parcurge șase etape: definirea cerințelor măsurabile, filtrarea eliminatorie a candidaților care nu satisfac cerințele obligatorii, evaluarea ponderată a celor rămași, construirea unui prototip pe platforma țintă reală, măsurători efective (latență, jitter, RAM/Flash, consum, comportament la suprasarcină) și, în final, decizia documentată - cu candidații eliminați, ipotezele folosite și condițiile care ar impune o reevaluare ulterioară.

13Erori frecvente5 min

• „Am protejat variabila cu volatile, deci e thread-safe." Fals - volatile influențează doar optimizările compilatorului, nu oferă excludere mutuală și nu transformă o secvență citire-modificare-scriere într-o operație atomică. Folosiți un mutex sau o operație atomică dedicată pentru accesul concurent real.
• „Un semafor binar poate înlocui întotdeauna un mutex." Nu - semafoarele nu au conceptul de proprietar, iar Priority Inheritance, în multe RTOS-uri, e implementat doar pentru mutex-uri. Înlocuirea unui mutex cu un semafor poate elimina, tăcut, protecția împotriva inversiunii de prioritate. Folosiți mutex pentru protejarea resurselor, semafor pentru semnalizare.
• „Priority Inheritance rezolvă complet inversiunea de prioritate, indiferent de cât durează secțiunea critică." Nu - PIP mărginește cine poate întârzia task-ul de prioritate mare, dar nu scurtează secțiunea critică în sine; o secțiune critică prost proiectată (operații lente, I/O blocant) rămâne o problemă indiferent de protocol. Păstrați secțiunile critice scurte, indiferent de protocolul de control al priorității folosit.
• „Un microkernel garantează, singur, un sistem mai sigur decât unul monolitic." Nu automat - microkernelul reduce codul privilegiat și izolează componentele, dar siguranța reală depinde de configurarea corectă a permisiunilor și de aplicarea principiului privilegiului minim. Evaluați configurația concretă, nu doar clasificarea arhitecturală generică.

14Rezumat și glosar5 min

Sincronizarea corectă a task-urilor concurente cere excludere mutuală pentru resursele partajate (mutex) și mecanisme dedicate de semnalizare (semafor, grup de evenimente, coadă de mesaje) - alegerea greșită între ele poate reintroduce, tăcut, condiții de cursă sau poate elimina protecții de care aplicația depinde fără să știe. Când task-uri cu priorități diferite partajează o resursă, poate apărea inversiunea de prioritate; Priority Inheritance și Priority Ceiling sunt cele două protocoale clasice care o mărginesc, cu compromisuri diferite între simplitate și predictibilitate. La nivelul kernelului, arhitectura monolitică oferă latență minimă dar izolare slabă, microkernelul oferă izolare mai bună cu un cost de comunicare; MPU/MMU aduc suportul hardware necesar izolării, iar sistemele multicore (AMP/SMP) și cele cu criticitate mixtă complică semnificativ analiza temporală. Selecția unui RTOS concret trebuie ghidată de cerințele verificabile ale produsului, nu de popularitatea unei platforme.

15Întrebări de verificare6 min

1. De ce operația counter++ nu e neapărat atomică, la nivel de procesor?
2. Care e diferența fundamentală dintre un mutex și un semafor?
3. Descrieți scenariul minimal de inversiune de prioritate, cu trei task-uri.
4. Cum reduce Priority Inheritance timpul de blocare al unui task de prioritate mare?
5. Ce garantează în plus Priority Ceiling față de Priority Inheritance?
6. Care e diferența principală dintre un kernel monolitic și un microkernel?
7. Ce poate, și ce nu poate, detecta protecția memoriei prin MPU?
8. Care e diferența dintre AMP și SMP pe un procesor multicore?

16Direcții de aprofundare2 min

Cursul următor trece de la sincronizarea și structura RTOS-ului la o direcție diferită: sistemele reconfigurabile și accelerarea hardware - de ce și când merită mutat un calcul din software în hardware dedicat (FPGA, accelerator), și ce compromisuri aduce această decizie.

Mutex-urile, semafoarele, grupurile de evenimente și protocoalele de control al priorității discutate aici devin cod real, verificabil pe hardware, în Laboratorul 03, alături de conceptele din Cursul 07.