Problema dell’inversione di priorità
La missione Mars Pathfinder (NASA) aveva come rover il Sojourner, che aveva un OS real-time. I sistemi real-time garantiscono che certi compiti devono essere eseguiti entro una scadenza precisa.
Questo OS aveva 3 thread :
- thread alta priorità (TH) : raccoglieva e analizzava dati scientifici importanti
- thread media priorità (TM) : compiti di routine come la comunicazione con la terra
- thread bassa priorità (TL): registrare dati e altre info meno importanti
Consideriamo :
- TL esegue il suo compito, ma per farlo acquisisce il mutex su una risorsa condivisa
- TH si attiva e siccome TH > TL, gli viene assegnata la CPU, ma trova la risorsa bloccata da TL, allora TH si mette in attesa che TL la liberi
- riprende TL
- TM si attiva e siccome TM > TL, gli viene assegnata la CPU. TM NON ha bisogno della risorsa condivisa e quindi esegue il suo compito come possiamo notare abbiamo la seguente situazione :
- TH non può riprendere perché è in attesa che TL rilasci la risorsa condivisa
- ma TL è in attesa (o bloccato) perché TM ha priorità su di lui
- e TM sta eseguendo
Quindi anche se TH ha priorità su di tutti, non può essere eseguito; proprio per questo, il problema è chiamato inversione delle priorità (priority inversion).
PIP
La soluzione della NASA è l’introduzione di una tecnica chiamata Priority Inheritance Protocol (PIP) :
- normalmente un TL che ha un mutex viene eseguito con la sua priorità (bassa)
- quando un TH inizia e vuole lo stesso mutex, il OS eleva temporaneamente la priorità del thread che ha il mutex (TL), portandola al livello del thread in attesa (TH) (TL TH) in questo modo un TL completa il suo lavoro rapidamente in modo da rilasciare (rapidamente) il mutex (senza interferenze di eventuali TM), consentendo ad un TH di procedere. Ricordiamo che una volta finito il lavoro il TH “fake” torna alla sua priorità originale (TH TL).
ANALOGIA per capire meglio :
