Scusate il ritardo, ma non sono riuscito a finire prima di partecipare a delle prove del nostro veicolo a guida autonoma. Ecco una versione rivista su alcuni punti della spiegazione dell'esempio presente sul testo (figura 6.14, il cui testo di spiegazione effettivamente aveva delle lacune, per cui andava inventata una soluzione, che poi doveva essere coerente con le altre informazioni disponibli).

La figura 6.14 illustra un esempio in cui un task τ1, con deadline hard real-time e worst-case computation time C1 = 4 and period T1 = 7, è da schedulare assieme ad un task τ2, con deadline soft real-time. La scelta è di servire τ2 con un CBS avente budget Qs = 3 e periodo Ts = 8 (Us= Qs / Ts = 0.375).

All'inizio τ2 non è released, pur essendo in linea teorica definita la sua deadline d0 = 0. Pertanto entra in esecuzione τ1 che procede indisturbato fino all'arrivo (release), al tempo t=3, del primo job di τ2 (J2,1); J2,1 ha r1=3 e WCET=4.

Al release di J2,1, τ2 era idle; la sua deadline diventa Ts=8 e cs viene impostato al valore Qs = 3. Lo scheduler deve ora valutare se cs è ≥ (d0 − r1) * Us; (0-3)*0.375 = -1.125; 3>-1.125 e quindi a J2,1 viene assegnata una deadline d1 = r1 + Ts = 3 + 8 = 11 e cs viene "ri"-caricato a Qs = 3 (aspetto secondario: lo era già, secondo me).

Siccome τ1 ha deadline 7 mentre τ2 ha deadline 11, lo scheduler manda (tiene) in esecuzione τ1.

A t=4 τ1 termina (la sua successiva release avverrà a t=7) e quindi il task con earliest deadline diviene τ2 che quindi entra in esecuzione. Per questo il cs inizia a decrescere linearmente (il punto di inflessione nella figura è un pochino a destra di t=4, secondo me è un errore di disegno). A t=7 cs si è azzerato e J2,1 non ha ancora completato la sua esecuzione (se per caso l'avesse invece completata perché in questa attivazione non richiedeva il tempo di caso pessimo si resterebbe con la cpu idle fino a t=7 perché non ci sono task released).

A t=7 non solo viene fermato τ2 perché è terminato il suo cs. Viene anche determinata la nuova deadline 11+8=19. Viene anche immediatamente ri-caricato cs a Qs=3. Siccome viene anche released la seconda istanza di τ1 che ha deadline 14, entra in esecuzione τ1.

Al tempo t=11 τ1 termina (la sua successiva release avverrà a t=14) e quindi il task con earliest deadline diviene τ2 che quindi entra in esecuzione, per la parte residua di J2,1. Per questo il cs inizia a decrescere linearmente. Al tempo t=12 J2.1 termina e τ2 quindi diventa idle, con un cs residuo pari a 2.

Al tempo t=13 arriva (release) J2,2, il secondo job di τ2. Il suo WCET è di 3. Siccome (d2 − r2) * Us = (19-13)*0.375 = 6*0.375=2.25 che è > cs (cs = 2), allora si procede con τ2 (stessa deadline ed il cs residuo).

A t=14 viene released la terza istanza di τ1 che ha deadline 21. Siccome τ2 è il task con earliest deadline, τ2 va (resta) in esecuzione.

Al tempo t=15 si esaurisce il cs di τ2 e J2,2 non ha ancora completato la sua esecuzione. A t=15 non solo viene fermato τ2 perché è terminato il suo cs. Viene anche determinata la sua nuova deadline 19+8=27. Viene anche immediatamente ri-caricato cs a Qs=3. Siccome a t=14 è stata già released la terza istanza di τ1 che ha deadline 21, entra in esecuzione τ1.

A t=19 finisce τ1 e τ2 diventa earliest deadline task, entra in esecuzione e ci resta fino a t=20, quando finisce J2,2, lasciando un cs residuo di 2.