How would you approach using D in a embedded real-time environment?

Question

To all those familiar with D programming language, how would go about using it in a embedded real-time environment? I understand that it's original design is not targeted for real-time embedded environments, but this question is more about how would you go about making real-time capability happen.

Which constructs of the language would be indispensable?

Which constructs do you see would be a problem?

Has anyone successfully used it in a embedded system?

Any other thoughts or suggestions would be great.

Answer 1

D isn't really meant for use in real-time applications, mostly because some language features of D rely on its garbage collector, and D's garbage collector is unpredictable and will sporadically pause your program to collect garbage. Quoting:

Garbage collection is not a panacea. There are some downsides:

• It is not predictable when a collection gets run, so the program can arbitrarily pause.
• The time it takes for a collection to run is not bounded. While in practice it is very quick, this cannot be guaranteed.
• All threads other than the collector thread must be halted while the collection is in progress.

You can still use D without a garbage collector (by managing memory manually, like in C/C++) - this will prevent you from using certain language features like associative arrays, and library functions that internally allocate memory without deallocating/returning a reference to it. D still excels in many areas not dependent on memory management (such as metaprogramming).

Answer 2

Real time is more about guarantees than "real time" performance. As such there are two possibilities;

• If you don't need GC dependent libraries, just avoid making your application/libraries dependent on it. Do this by always making sure you have uncontrolled allocations, and preferably no allocations at all during the actual running of the application (allocate up front).
• There has been research into real time GC's in other languages. This is not trivial though, and may cause more slow downs than what you are willing to pay for your guarantees. The requirements are that the GC is implemented such that time spent on any operation has an upper bound, and that the compiler is implemented such that it can help by inserting barriers (would also be needed by a non-RT moving GC).