Come ti avvicineresti a usare D in un ambiente embedded in tempo reale?

Question

Per tutti coloro che hanno familiarità con D programming language, come fare per utilizzarlo in un ambiente embedded in tempo reale? Capisco che il suo design originale non è mirato agli ambienti embedded in tempo reale, ma questa domanda riguarda più come faresti le capacità in tempo reale.

Quali costrutti della lingua sarebbero indispensabili?

Quali costrutti vedete sarebbe un problema?

Qualcuno l'ha usato con successo in un sistema embedded?

Qualsiasi altro pensiero o suggerimento sarebbe ottimo.

Answer 1

D non è pensato per l'uso in applicazioni in tempo reale, soprattutto perché alcune funzionalità linguistiche di D si basano sul suo garbage collector e il garbage collector di D è imprevedibile e interromperà il programma in modo sporadico per raccogliere i rifiuti. Quoting:

La raccolta dei rifiuti non è una panacea. Ci sono alcuni aspetti negativi:

• Non è prevedibile quando una raccolta viene eseguita, quindi il programma può sospendere arbitrariamente.
• Il tempo necessario per l'esecuzione di una raccolta non è limitato. Mentre in pratica è molto veloce, questo non può essere garantito.
• Tutti i thread diversi dal thread del raccoglitore devono essere fermati mentre la raccolta è in corso.

È comunque possibile utilizzare D senza un garbage collector (attraverso la gestione della memoria a mano, come in C/C++) - questo ti impedirà di utilizzare alcune funzionalità del linguaggio come array associativi, e funzioni di libreria che allocano internamente la memoria senza deallocare/restituire un riferimento ad esso. D eccelle ancora in molte aree che non dipendono dalla gestione della memoria (come la metaprogrammazione).

Answer 2

In tempo reale sono più le garanzie che le prestazioni "in tempo reale". Come tale ci sono due possibilità;

• Se non sono necessarie librerie dipendenti da GC, è sufficiente evitare di rendere l'applicazione/le librerie dipendenti da esso. Fai questo assicurandoti sempre di avere allocazioni incontrollate e preferibilmente nessuna allocazione durante l'esecuzione effettiva dell'applicazione (allocare in anticipo).
• C'è stata una ricerca su GC in tempo reale in altre lingue. Tuttavia, ciò non è banale e potrebbe causare rallentamenti più lenti rispetto a quanto si è disposti a pagare per le proprie garanzie. I requisiti sono che il GC sia implementato in modo tale che il tempo speso per qualsiasi operazione abbia un limite superiore e che il compilatore sia implementato in modo tale che possa aiutare inserendo barriere (sarebbe anche necessario per un GC in movimento non RT).