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.
  1. 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.
  2. 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.
  3. 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:
    1. Use a mutex or synchronized statement to wait for heap-using code.
    2. Use a system service that uses mutexes and might be used by heap-using code.
    3. Give heap-using code a higher priority than some no-heap code.
  4. 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.
  5. 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.
  6. 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.
  7. I like to subclass RealtimeThread and attach logic by overriding the run() method. It seems clearer than using separate logic with a bare RealtimeThread.
  8. Don't use no-heap mode unless you really have to. It's hard to use and the code tends to be fragile.
  9. 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.
  10. Unchecked exceptions (the big ones in RTSJ are MemoryAccessError and 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.