Tnkernel mutexes pic24

Mutex este un obiect RTOS conceput pentru a oferi acces competitiv la resursele partajate. Mutexul este un semafor binar cu proprietăți suplimentare (de exemplu, ocolind protocoalele de inversiune prioritară nelimitată).







Mutexul poate fi în două stări: blocat și deblocat. Mutex asociată cu resurse hardware sau software de aplicație, poate asigura accesul corect la resursele unui număr de sarcini - în cazul în care sarcina încearcă să acceseze resursele blocate, acesta va fi tradus într-o stare de repaus, dar va obține controlul imediat după resursa este deblocat.

De multe ori apare întrebarea - de ce trebuie să blocați resursele? Este vorba despre principiul de a împinge RTOS - sarcina poate fi întreruptă (înlocuită) în orice moment. Dacă în acel moment utilizează o anumită resursă de sistem (de exemplu, UART) și sarcina care a înlocuit cea actuală va începe să lucreze cu aceasta - va apărea un conflict natural.

Odată cu blocarea resurselor, noțiunea de inversiune prioritară este strâns legată:

Tnkernel mutexes pic24

Să presupunem că în sistem există două probleme cu prioritate scăzută (A) și mare (B). La momentul T1, sarcina (A) blochează resursa și începe să o serviceze. La momentul T2, sarcina (B) înlocuiește sarcina cu prioritate scăzută (A) și încearcă să profite de resurse la momentul T3. Dar, deoarece resursele sunt blocate, sarcina (B) este pusă în așteptare, iar sarcina (A) continuă execuția. La momentul T4, sarcina (A) completează întreținerea resursei și o deblochează. Deoarece resursele așteaptă sarcina (B), aceasta începe imediat să execute.

Intervalul de timp (T4-T3) se numește o inversare cu prioritate limitată. În această diferență există o inconsecvență logică cu regulile de planificare - o sarcină cu o prioritate mai mare așteaptă în timp ce sarcina cu prioritate scăzută este executată.

Dar asta nu este cel mai rău. Să presupunem că sistemul are trei sarcini: prioritate scăzută (A), prioritate medie (B) și prioritate ridicată (B):

Tnkernel mutexes pic24

Dacă resursa este blocată de sarcina (A) și este necesară pentru sarcina (B), atunci se observă aceeași situație - sarcina cu prioritate ridicată este blocată. Dar să presupunem că sarcina (B) a înlocuit (A), după ce (B) a așteptat resursa. Sarcina (B) nu cunoaște nimic despre conflict, deci poate fi făcută arbitrar lung într-un interval de timp (T5-T4). În plus, pe lângă (B), pot exista alte sarcini în sistem, cu priorități mai mari decât (A), dar mai puțin (B). Prin urmare, durata perioadei (T6-T3) este, în general, nedefinită. Această situație se numește inversiune prioritară nelimitată.







Inversiunea limitată a priorităților în cazul general nu poate fi evitată, însă nu este la fel de periculoasă pentru sistem ca fiind nelimitată. Pentru a evita inversarea prioritară nelimitată, se folosesc două protocoale pentru schimbarea priorităților sarcinii:

Protocolul prioritar de moștenire

Protocolul privind plafonul prioritar

Să presupunem că în sistem există două probleme cu prioritate scăzută (A) și mare (B):

Tnkernel mutexes pic24

La momentul T2 problema (B) dislocă sarcină scăzută prioritate (A) și apoi la momentul de timp T3 este încercarea de a captura resursa (A) blocat.

Protocolul prioritar de mostenire este că prioritatea de sarcină (A) este ridicată la prioritatea sarcinii (B) în momentul T3, adică când (B) încearcă să capteze resursele blocate. Astfel, sarcinile cu prioritate mai mare decât (A) dar mai puțin (B) nu pot implementa inversiunea nelimitată, iar sarcina (B) va primi resursa imediat după (A) deblocarea.

După ce sarcina (A) deblochează resursa, prioritatea sa este redusă la cea inițială.

Protocolul pentru creșterea priorității se bazează pe faptul că în momentul proiectării sunt cunoscute toate sarcinile care necesită o anumită resursă și sunt cunoscute prioritățile acestor sarcini. În acest caz, resursei (mutex) i se poate atribui o proprietate specifică - cea mai mare prioritate a tuturor sarcinilor care o pot bloca (plafonul).

Să presupunem că sistemul are trei sarcini cu prioritate scăzută (A), medie (B) și mare (B), care poate bloca o resursă:

Tnkernel mutexes pic24

La momentul T3, când sarcina (B) încearcă să capteze resursele blocate (A), prioritatea (A) crește la prioritatea sarcinii (B), adică până la prioritatea maximă a tuturor sarcinilor care pot deține o resursă. Odată ce sarcina (A) eliberează o resursă la momentul T4, prioritatea acesteia este redusă la original, iar prioritatea sarcinii (B) care așteaptă o creștere a resursei (B).

Astfel, folosind protocolul de creștere a priorității sarcinilor de resurse confiscate este întotdeauna are cel mai mare grup de prioritate de sarcini, care poate stoca această resursă. Acest lucru permite nu numai să scape de inversarea prioritară nelimitată, ci și să împiedice blocarea reciprocă.

Închiderea reciprocă este o stare de urgență a sistemului care poate apărea atunci când se blochează resursele. Să presupunem că sistemul are două probleme cu prioritate mică (A) și mare (B), care utilizează două resurse - X și Y:

Tnkernel mutexes pic24

La T1 problema (A) timp blochează X. resursa Apoi, la momentul T2 problema (A), dislocă sarcina cu prioritate mai mare (B), care la momentul respectiv blocurile de resurse T3-timp Y. În cazul în care sarcina (B) va încerca pentru a bloca resursa X (T4) fără a elibera resursa Y, va fi pusă în stare de așteptare și sarcina (A) va fi continuată. Dacă în timpul sarcinii T5 (A) încearcă să blocheze resursa Y, deși nu eliberează X, nu există condiții de blocare - nici una dintre problemele (A) și (B) să nu fie în măsură să controleze.

Închiderea reciprocă este posibilă numai dacă sistemul folosește acces competitiv imbricat la resurse. Închiderea reciprocă poate fi evitată dacă nu utilizați cuiburile sau dacă resursa utilizează un protocol de creștere a priorității.

TNKernel implementează mutexuri atât cu un protocol de moștenire prioritar, cât și cu un protocol de creștere a priorității.

Protocolul prioritar de moștenire este mai simplu și mai rapid, dar nu împiedică blocarea reciprocă. Prin urmare, pentru astfel de mutexuri, nu se recomandă utilizarea accesului imbricat. Protocolul de creștere a priorității necesită mai multe resurse de timp și asigură faptul că nu există interblocare reciprocă.

Fiecare mutex este asociat cu o structură de management:

Structura mutexului include următoarele elemente:

Coada de sarcini așteptând eliberarea mutexului







Trimiteți-le prietenilor: