Quali sono i motivi per cui uno stack Java / Linux non riesce a essere "in tempo reale"?

Ho spesso sentito gli sviluppatori menzionare che Java non può " fare Real Time ", il che significa che un'app Java in esecuzione su Linux non può soddisfare i requisiti di un sistema deterministico in tempo reale, come qualcosa in esecuzione su RIOT-OS, ecc.

Sto cercando di capire il perché . Il mio SWAG mi dice che ciò è probabilmente dovuto in gran parte al Garbage Collector di Java, che può essere eseguito in qualsiasi momento e mettere completamente in pausa il sistema. E anche se ci sono i cosiddetti "GC senza pause" là fuori, non credo necessariamente alla loro pubblicità, e non ho nemmeno $ 80K-per-istanza JVM da sborsare per un progetto di hobby!

Stavo anche leggendo questo articolo sull'esecuzione di software per droni su Linux . In quell'articolo, l'autore descrive uno scenario in cui Linux ha quasi causato il crash del suo drone nella sua auto:

Ho imparato una dura lezione dopo aver scelto di fare il loop di controllo a basso livello (PID) sul Pi - cercando di essere intelligente, ho deciso di mettere una scrittura di log nel mezzo del loop per il debug - il quad inizialmente ha funzionato bene ma poi Linux ha deciso impiegare 2 secondi per scrivere una voce di registro e il quad si è quasi schiantato contro la mia macchina!

Ora, sebbene quell'autore abbia scritto il suo software per droni in C ++, immagino che un'app Java in esecuzione su Linux possa benissimo subire lo stesso destino.

Secondo Wikipedia:

Si dice che un sistema è in tempo reale se la correttezza totale di un'operazione dipende non solo dalla sua logica logica, ma anche dal tempo in cui viene eseguita.

Quindi, per me, questo significa " Non hai tempo reale se la correttezza totale richiede correttezza logica e tempestività " .

Facciamo finta di aver scritto un'app Java per essere super performante e di aver "spremuto il limone" per così dire, e che non poteva ragionevolmente essere scritto (in Java) per essere più veloce.

Tutto sommato, la mia domanda è: sto cercando qualcuno che mi spieghi tutti / la maggior parte dei motivi per cui un'app Java che esegue n Linux non sarebbe un'app in tempo reale. Significato, quali sono tutte le categorie di cose su uno stack Java / Linux che gli impediscono di "essere tempestive" e, quindi, di essere " totalmente corrette "? Come accennato, sembra che il flushing dei log di GC e Linux possa mettere in pausa l'esecuzione, ma sono sicuro che ci sono più cose al di fuori della stessa app Java che potrebbero causare tempi / prestazioni scadenti e far sì che rispetti i vincoli di scadenza. Quali sono?

Un software è in tempo reale non quando è il più veloce possibile, ma quando è garantito che un processo venga completato entro un determinato intervallo di tempo. In un sistema soft in tempo reale, è buono ma non assolutamente necessario che ciò sia garantito. Ad esempio in un gioco, i calcoli necessari per un fotogramma dovrebbero essere completati entro il periodo di un fotogramma, altrimenti il ​​framerate scenderà. Ciò degrada la qualità del gameplay, ma non lo rende errato. Ad esempio Minecraft è divertente anche se il gioco occasionalmente balbetta.

In un sistema in tempo reale difficile, non abbiamo tali libertà. Un software di controllo del volo deve reagire entro una scadenza o il veicolo potrebbe schiantarsi. E l'hardware, il sistema operativo e il software devono collaborare per supportare il tempo reale.

Ad esempio, il sistema operativo ha uno scheduler per decidere quando eseguire il thread. Per un programma in tempo reale, lo scheduler deve garantire intervalli di tempo abbastanza grandi e abbastanza frequenti. Qualsiasi altro processo che desideri eseguire in tale slot deve essere interrotto a favore del processo in tempo reale. Ciò richiede uno scheduler con supporto esplicito in tempo reale.

Inoltre, un programma spazio utente eseguirà chiamate di sistema nel kernel. In un sistema operativo in tempo reale, anche questi devono essere in tempo reale. Ad esempio, la scrittura su un handle di file dovrebbe essere garantita in modo da non richiedere più di x unità di tempo, il che risolverà il problema del registro. Ciò incide sul modo in cui una tale chiamata di sistema può essere implementata, ad esempio su come utilizzare i buffer. Significa anche che una chiamata deve fallire se non può essere completata entro il tempo richiesto e che il programma spazio utente deve essere preparato per affrontare questi casi. Nel caso di Java, anche JVM e la libreria standard sono simili al kernel e richiederebbero un supporto esplicito in tempo reale.

Per tutto ciò che è in tempo reale, il tuo stile di programmazione cambierà. Se non hai tempo infinito, devi limitarti a piccoli problemi. Tutti i tuoi loop devono essere delimitati da una costante. Tutta la memoria può essere allocata staticamente, poiché hai un limite superiore per le dimensioni. È vietata la ricorsione senza restrizioni. Questo va contro molte buone pratiche, ma non si applicano ai sistemi in tempo reale. Ad esempio, un sistema di registrazione potrebbe utilizzare un buffer ad anello allocato staticamente per memorizzare i messaggi di registro quando vengono scritti. Una volta raggiunto l'inizio, i vecchi registri verrebbero eliminati o questa condizione potrebbe essere un errore.

Da Wikipedia :

Una caratteristica chiave di un RTOS è il livello della sua coerenza per quanto riguarda il tempo necessario per accettare e completare l'attività di un'applicazione; la variabilità è jitter.

L'importante è che il jitter sia quantificato affinché il sistema sia considerato in tempo reale . L'articolo continua dicendo che se il jitter è solitamente limitato, il sistema è morbido in tempo reale . Se il jitter è sempre limitato, il sistema è difficile in tempo reale .

A meno che le versioni di Java e Linux utilizzati siano quantificati in termini di jitter, sono non in tempo reale. Raccolta dei rifiuti e di log-scrittura sono certamente fonti di jitter, ma l'elaborazione anche autonoma di (ad esempio) i pacchetti di rete conta se si introduce jitter nei vostri processi.

Per cominciare, il vanilla Linux stesso non può fare in tempo reale. Ecco perché è stato sviluppato RTLinux .

Supponiamo che tu esegua alcuni processi Java su RTLinux, sarebbero comunque considerati in tempo reale poiché tutti quei processi sono programmati dal kernel, cioè se un processo è in ritardo, altri processi possono comunque avere la loro fetta di tempo della CPU, garantita.

Ora, se i processi java eseguono thread verdi , l'esecuzione di questi thread non sarà più in tempo reale poiché la JVM non esegue la pianificazione in tempo reale.