Quali garanzie offrono effettivamente i sistemi operativi "soft" in tempo reale

Penso di sapere cos'è un sistema operativo in tempo reale "difficile". È un sistema operativo con uno scheduler che fornisce un contratto con il programmatore dell'applicazione. Un'applicazione fornisce una scadenza per ogni richiesta di allocazione delle risorse. Se le richieste di scadenza sono realizzabili , lo scheduler garantisce che ogni risorsa verrà allocata all'applicazione richiedente prima della scadenza. La garanzia è sufficiente per consentire a un programmatore dell'applicazione di ragionare sulle latenze massime e sui throughput minimi di richieste specifiche.

Tutte le definizioni che trovo di sistemi "soft" in tempo reale mi sembrano vacue. Dice Wikipedia

l'utilità di un risultato si riduce dopo la scadenza, degradando così la qualità del servizio del sistema.

Uhhhh. Va bene. In base a tali criteri, Windows 95 era un sistema soft in tempo reale, così come 3BSD e anche Linux. Wikipedia non è una grande fonte, ma i prossimi successi di Google non saranno molto migliori. Ad esempio http://users.ece.cmu.edu/~koopman/des_s99/real_time/ afferma

In un sistema soft in tempo reale, un'operazione degradata in un carico di picco che si verifica raramente può essere tollerata.

Non è un contratto, è un modo stravagante di non dire nulla.

Quali sono esempi di garanzie / contratti reali in tempo reale offerti da sistemi operativi reali?

Sto cercando le risposte del modulo:

In (nome OS) se il programmatore fa (cosa deve fare il programmatore), il sistema operativo garantisce (cosa garantisce il sistema).

Hai capito bene e Wikipedia è il più informativo possibile: il soft real-time non è una caratterizzazione formale, è un giudizio di valore. Un altro modo per dire "soft in tempo reale" è "Vorrei che fosse in tempo reale", o forse più precisamente "dovrebbe essere in tempo reale ma è troppo difficile".

Se vuoi davvero esprimerti sotto forma di una garanzia, è una garanzia del miglior sforzo piuttosto che una garanzia di prestazioni specifiche.

Oppure, per citare le FAQ di Erlang (Erlang è un linguaggio di programmazione originariamente progettato per l'uso in telefonia):

Cosa significa soft realtime?

I cinici diranno "praticamente niente".

... I sistemi soft realtime, come Erlang, ti offrono questo tipo di garanzia.

E questo fornisce una definizione utile. Il soft real-time indica un design che è ottimizzato per ogni singola attività impiegando non più di un certo tempo , piuttosto che per ottimizzare il tempo totale impiegato per eseguire tutte le attività. Ad esempio, un sistema soft in tempo reale dovrebbe mirare a completare il 99,9% delle richieste in 10 ms ed elaborare 100 richieste al secondo, laddove un tempo non in tempo reale potrebbe mirare a procedere 200 richieste al secondo ma consentire a richieste occasionali di bloccare per 50ms o più. Un duro tempo reale garantirebbe una richiesta ogni 15ms, non importa quale.

Il soft real-time viene utilizzato per applicazioni in cui una scadenza mancata comporta un degrado del servizio, ma non è critico per le prestazioni. Multimedia e telefonia sono alcuni casi d'uso tipici. Ogni fotogramma audio o video deve essere renderizzato nel tempo, altrimenti deve essere ignorato; ma saltare una cornice non è la fine del mondo. I progettisti di Erlang avevano obiettivi simili in termini di affidabilità in altre questioni: hanno osservato che era meglio che uno scambio telefonico facesse cadere una telefonata molto occasionalmente, ma per essere assolutamente sicuri che lo scambio nel suo insieme avrebbe continuato a funzionare, qualunque cosa potesse, piuttosto che rischiare mai un fallimento catastrofico nel tentativo di mantenere le connessioni a tutti i costi.

Al contrario, qualcosa come il controllo di un motore richiede che il software non salti mai una scadenza. Questo ha dei costi: le prestazioni complessive sono generalmente più lente e si possono ottenere solo comportamenti relativamente semplici. Dall'altro lato dello spettro, un'applicazione per lo scricchiolio dei numeri in genere si preoccupa solo delle prestazioni complessive: ciò che conta è la velocità con cui si moltiplicano le matrici 1000x1000, non la velocità con cui viene calcolata ciascuna colonna.

Linux con il patchset -rt (in tempo reale) fornisce uno scheduler che fornisce un'interessante garanzia che sembra non vacua. (Anche se non sono chiaro su come la garanzia possa essere messa in pratica.)

Linux-rt SCHED_FIFO politica di pianificazione di funziona come segue: l'utente assegna una priorità a ogni processo. (I numeri di priorità per i processi "in tempo reale" sono 0-99 e i nicevalori Unix tradizionali da -20 a 19 corrispondono alle priorità da 100 a 139. (Quindi "0" è la priorità "più alta" e "139" è la "più bassa "priorità.)

La garanzia è che in qualsiasi momento lo scheduler pianificherà i Nlavori eseguibili con la priorità più alta su una Nmacchina con processore. Sono stati fatti grandi sforzi per evitare problemi di inversione prioritaria all'interno del kernel. Quando il processo Adiventa eseguibile e ha una priorità più alta rispetto ad altri processi in esecuzione B,A viene immediatamente escluso B.

Si noti, tuttavia, che non esistono garanzie temporali rigide. Il tempo effettivamente impiegato per eseguire la prelazione potrebbe teoricamente essere arbitrariamente lungo. Inoltre, sembrano esserci alcuni modi in cui un lavoro a bassa priorità potrebbe avviare un gruppo di I / O a lunga latenza. Una volta completato l'I / O, i gestori di interrupt per il processo a bassa priorità potrebbero interrompere un processo a priorità più elevata, che è, probabilmente, una forma di inversione di priorità.

Quindi la garanzia limitata fornita è: se esiste un singolo processo con la massima priorità, ogni volta che è eseguibile otterrà tutte le risorse del processore che il sistema operativo può realisticamente fornirgli. Se si dispone di un buon limite superiore per la quantità di risorse del processore consumate dal processo con priorità più elevata, è possibile calcolare una stima ragionevolmente accurata delle risorse che saranno disponibili per il processo con priorità più alta e così via.

Un articolo approfondito che descrive lo scheduler in tempo reale di Linux è http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .

Per definire "soft in tempo reale", è più semplice confrontarlo con "hard in tempo reale".

Parlando casualmente, la maggior parte delle persone ha implicitamente un modello mentale informale che considera le informazioni o un evento come "in tempo reale"

• se, o nella misura in cui, si manifesta con loro un ritardo (latenza) che può essere correlato alla sua valuta percepita

• vale a dire, in un arco di tempo in cui le informazioni o l'evento hanno un valore accettabilmente soddisfacente per loro.

Esistono numerose diverse definizioni ad hoc di "hard real-time", ma in quel modello mentale, hard real-time è rappresentato dal termine "if". In particolare, supponendo che le azioni in tempo reale (come le attività) abbiano scadenze di completamento, il valore accettabilmente soddisfacente dell'evento che tutte le attività completate è limitato al caso speciale in cui tutte le attività rispettano le loro scadenze.

I sistemi hard-time realizzano le ipotesi molto forti secondo cui tutto ciò che riguarda l'applicazione, il sistema e l'ambiente è statico e noto a priori, ad es. Quali compiti, che sono periodici, i loro tempi di arrivo, i loro periodi, le loro scadenze, che hanno vinto non hanno conflitti di risorse e, nel complesso, l'evoluzione temporale del sistema. In un sistema di controllo del volo di un aeromobile o in un sistema di frenatura automobilistica e in molti altri casi, tali ipotesi possono in genere essere soddisfatte affinché siano rispettate tutte le scadenze.

Questo modello mentale è deliberatamente e utilmente abbastanza generale da comprendere sia il duro che il morbido in tempo reale - il morbido è accomodato dalla frase "nella misura in cui". Ad esempio, supponiamo che l'evento di completamento dell'attività abbia un valore non ottimale ma accettabile se

• non più del 10% delle attività non rispetta le scadenze
• o nessuna attività è più del 20% tardiva
• o il ritardo medio di tutte le attività non supera il 15%
• o il massimo ritardo tra tutte le attività è inferiore al 10%

Questi sono tutti esempi comuni di casi soft in tempo reale in molte applicazioni.

Prendi in considerazione l'applicazione per attività singole di andare a prendere tuo figlio dopo la scuola. Che probabilmente non ha una scadenza effettiva, invece c'è un valore per te e tuo figlio in base a quando l'evento si svolge. Sprecare risorse troppo presto (come il tuo tempo) e troppo tardi ha un valore negativo perché tuo figlio potrebbe essere lasciato solo e potenzialmente in pericolo (o almeno disturbato).

A differenza del caso speciale statico rigido in tempo reale, il soft real-time fa solo le ipotesi minime necessarie specifiche dell'applicazione relative alle attività e al sistema e sono attese incertezze. Per andare a prendere tuo figlio, devi guidare fino a scuola e il tempo per farlo è dinamico a seconda del tempo, delle condizioni del traffico, ecc. Potresti essere tentato di eseguire il provisioning eccessivo del tuo sistema (ad esempio, consentire ciò che speri sia il nel peggiore dei casi il tempo di guida), ma di nuovo si tratta di sprecare risorse (tempo e occupare il veicolo familiare, forse negando l'uso da parte di altri membri della famiglia).

Tale esempio potrebbe non sembrare costoso in termini di risorse sprecate, ma prendere in considerazione altri esempi. Tutti i sistemi di combattimento militari sono morbidi in tempo reale. Ad esempio, considera di eseguire un attacco aereo su un veicolo terrestre ostile usando un missile guidato con aggiornamenti ad esso come manovre bersaglio. La massima soddisfazione per il completamento delle attività di aggiornamento del corso è raggiunta da un attacco distruttivo diretto sul bersaglio. Ma un tentativo di sovra-approvvigionamento di risorse per accertarsi di questo risultato è di solito troppo costoso e potrebbe persino essere impossibile. In questo caso, potresti essere meno ma sufficientemente soddisfatto se il missile colpisce abbastanza vicino al bersaglio da disabilitarlo.

Ovviamente gli scenari di combattimento hanno molte possibili incertezze dinamiche che devono essere gestite dalla gestione delle risorse. I sistemi soft in tempo reale sono anche molto comuni in molti sistemi civili, come l'automazione industriale, sebbene ovviamente quelli militari siano i più pericolosi e urgenti per raggiungere un valore accettabilmente soddisfacente.

La chiave di volta dei sistemi in tempo reale è la "prevedibilità". Il difficile caso in tempo reale è interessato solo a un caso speciale di prevedibilità, ovvero che i compiti rispettino tutte le scadenze e che il massimo valore possibile sarà raggiunto da quell'evento. Quel caso speciale è chiamato "deterministico".

C'è uno spettro di prevedibilità; la maggior parte dei sistemi in tempo reale (vale a dire quelli soft) hanno una prevedibilità non deterministica, ad esempio, dei tempi di completamento delle attività e quindi dei valori acquisiti da tali eventi. In generale, la prevedibilità, e quindi il valore, possono essere fatti il ​​più vicino possibile all'end-point deterministico se necessario, ma a un prezzo che può essere fisicamente impossibile o eccessivamente costoso (come nel combattimento o forse anche nel prendere il bambino da scuola).

Il soft real-time richiede una scelta specifica dell'applicazione di un modello di probabilità (non il comune modello frequentista) e quindi un modello di prevedibilità per ragionare sulle latenze degli eventi e sui valori risultanti.

Facendo riferimento all'elenco sopra riportato di eventi che forniscono un valore accettabile, ora possiamo aggiungere casi non deterministici, come ad esempio

• la probabilità che nessuna attività salti la scadenza di oltre il 5% è maggiore di 0,87.

In un'applicazione di difesa missilistica, dato che in combattimento l'offesa ha sempre il vantaggio rispetto alla difesa, quale di questi due scenari di calcolo in tempo reale preferiresti:

• poiché la perfetta distruzione di tutti i missili ostili è molto improbabile o impossibile, assegna le tue risorse difensive per massimizzare la probabilità che altrettanti missili ostili più minacciosi (ad esempio, basati sui loro obiettivi) vengano intercettati con successo (l'intercettazione stretta conta perché può spostare il missile ostile fuori rotta);

• lamentarsi del fatto che questo non è un problema di elaborazione in tempo reale perché è dinamico anziché statico e i concetti e le tecniche in tempo reale tradizionali non si applicano, quindi non siete interessati a fare ricerca e sviluppo per il soft real-time.

Nonostante i vari fraintendimenti sul soft real-time nella comunità informatica in tempo reale (ma non in altri campi non informatici), il soft real-time è molto generale e potente e potenzialmente molto complesso rispetto al hard real-time.

Per rispondere direttamente alla domanda OP:

• un sistema in tempo reale difficile può fornire garanzie deterministiche - più comunemente che tutte le attività rispettano le scadenze, interrompono o i tempi di risposta alle chiamate di sistema saranno sempre inferiori a x, ecc. — SE E SOLO SE vengono fatte ipotesi molto forti e sono corrette che tutto ciò che conta è statico e noto a priori (in generale, tali garanzie per sistemi in tempo reale difficili sono un problema di ricerca aperta tranne casi piuttosto semplici)

• un sistema soft in tempo reale non fornisce garanzie deterministiche, è destinato a fornire la migliore tempestività probabilistica e prevedibilità analiticamente specificate possibili in condizioni dinamiche attuali, secondo criteri specifici dell'applicazione. Ovviamente hard real-time è un semplice caso speciale di soft real-time. Ovviamente le garanzie analitiche non deterministiche in tempo reale possono essere molto complesse da fornire, ma sono obbligatorie nei casi più comuni in tempo reale (compresi quelli più pericolosi in termini di sicurezza come il combattimento) poiché la maggior parte dei casi è dinamica non statica.

Ho una discussione dettagliata molto più precisa su tempo reale, tempo reale difficile, tempo reale morbido, prevedibilità, determinismo e argomenti correlati sul mio sito web real-time.org .