This is a list of some of my opinions about RTSJ programming. They are not in any order (not even chronological), and I am likely to alter them at moment's notice when I find that I no longer agree with myself.
- Try to keep objects out of immortal memory. It's any easy solution for assignment rule and reference rule problems, but objects in immortal memory tend to suck in other objects.
- Remember that exceptions are objects (that use memory), and they may use additional memory for their stack trace information. This memory consumption makes exceptions a poor choice for program control except when they are used in heap memory.
- No-heap means that the garbage collector will not, by itself, block your execution. There are still plenty of ways no-heap code can be delayed by garbage collection; for instance:
- Use a mutex or synchronized statement to wait for heap-using code.
- Use a system service that uses mutexes and might be used by heap-using code.
- Give heap-using code a higher priority than some no-heap code.
- Neither real-time threads nor no-heap real-time threads guarantee good real-time performance. (Sarcasm coming) The developer is free to use many techniques to give the code poor real-time characteristics.
- Except for
waitForNextPeriod(), a real-time thread can only be released once. This is a degenerate case of aperiodic scheduling, and makes no sense at all for sporadic scheduling. A real-time thread will take sporadic parameters, but they only make sense for async event handlers.
- Try to have useful no-arg constructors even if you have to build the object in two steps—construct with a no-arg constructor, setup. That way the no-arg constructor can be used with a simple
newInstance method and the setup/initialize method (or methods) can complete the new object. The potential problem is that the object exists but is not ready to use between construction and completion of initialization.
- I like to subclass
RealtimeThread and attach logic by overriding the
run() method. It seems clearer than using separate logic with a bare
- Don't use no-heap mode unless you really have to. It's hard to use and the code tends to be fragile.
- The standard libraries are surprisingly likely to work in scoped memory or no-heap mode. A lot of library code allocates objects, but the caller can manage that with an enclosing scoped memory.
- Unchecked exceptions (the big ones in RTSJ are
IllegalAssignmentError) are a sign of a bug in the application. They appear unexpectedly and may damage data structures by unceremoniously jumping to a (possibly distant) catch clause. Unless you can repair all the consequences of the exception, they should probably be considered fatal to the application.