This discussion is archived
3 Replies Latest reply: Aug 9, 2007 6:08 PM by 807557 RSS

Standard class library for real-time?

807557 Newbie
Currently Being Moderated
One of the challenges when using the RTSJ is the lack of a standard class library. The rich Java API from the standard edition is basically unusable because java.lang, java.util, etc. were not designed for time predictability and are not scope-safe. Building real-time software without these essential classes can really slow down productivity.

The only solution I know of is Javolution (http://javolution.org/), but it's a third-party library. Sun hasn't endorsed it -- or any other library -- for the RTSJ.

So I'm wondering: What do most RTSJ developers do when they need to use collection classes, or a simple string, or whatever? Do they roll their own classes? Do they simply use Javolution? Or is there some other solution I'm not aware of?

Thanks for any insight.
  • 1. Re: Standard class library for real-time?
    807557 Newbie
    Currently Being Moderated
    One of the challenges when using the RTSJ is the lack
    of a standard class library. The rich Java API from
    the standard edition is basically unusable because
    java.lang, java.util, etc. were not designed for time
    predictability and are not scope-safe.
    There are certainly issues that can arise when trying to use the standard libraries with both NoHeapRealtimeThreads (NHRT) and from ScopedMemory, but to say they are "unusable" is an over-statement and an over generalization.

    Where trouble arises is when mutable objects are used in mixed contexts: either shared by heap and non-heap entities; or accessed/used from different memory areas. For mutable data structures this invariably leads to problems. However there are a number of steps you can take to mitigate the problems:

    - avoid/minimize sharing across these contexts, and be aware of sharing so that problems can be avoided
    - recognize potential problems and avoid them, for example
    - ensure collections are big enough so they don't need to dynamically grow
    - perform initial accesses in the right memory area to ensure lazy initialization does not cause problems
    - explicitly switch memory areas to perform certain actions

    Testing tends to reveal these problems fairly early.

    The more general-purpose the programming you try to do from a NHRT or ScopedMemory, the more likely you will run into problems. But NHRTs and use of ScopedMemory is intended for time critical threads and they tend not use to use general purpose libraries (for a range of reasons). Rather the critical threads will hand-off data for use by real-time threads or plain java.lang.Threads, and those other threads will then safely use the standard libraries.

    I also like to use ScopedMemory as a "temporary space" for real-time threads, but in that case I know I have to take care when dealing with the non-temporary results.

    Once you realize that certain issues/limitations exist, it is fairly easy to work-around them.

    Cheers,
    David Holmes
  • 2. Re: Standard class library for real-time?
    807557 Newbie
    Currently Being Moderated
    Hmm... I'm curious how you feel about Javolution. Sounds like you're saying it solves a problem that doesn't exist, since one can just use the standard class library.

    But the extra steps you mentioned (avoiding context sharing, preventing collections from growing, etc.) have a pretty big impact on productivity. Having to do that extra work doesn't make the Java API very usable IMHO. Javolution, on the other hand, eliminates most of those steps. For instance, collections in Javolution can grow dynamically because they don't incur the expensive resize/copy or rehash operations. (See http://javolution.org/api/javolution/util/FastTable.html)
  • 3. Re: Standard class library for real-time?
    807557 Newbie
    Currently Being Moderated
    Hmm... I'm curious how you feel about Javolution.
    I haven't looked at Javolution in any detail so I can't comment on what it does specifically.
    Sounds like you're saying it solves a problem that
    doesn't exist, since one can just use the standard
    class library.
    No that wasn't what I said.

    The problem exists, but it is not as bad, or unmanageable as was made out. There are still issues and specialized class libraries may well address those issues more easily than working around things. But I'd say we are still in the "discovery" phase for working in this area. I've seen code where using the standard libraries in the real-time code just wasn't an issue.

    But as I said previously, the more general purpose computing you do in these specialized contexts, the more problems you will run into. So custom libraries, designed for real-time can certainly have a role to play.

    I'd like to see a JSR for javax.realtime.util, but I'm not sure we (the community) really understand yet what needs to be in there. I'm also a fan of the "try before you buy" approach - ref the java.util.concurrent libraries that existed for years as Doug Lea's libraries before they morphed into j.u.c
    But the extra steps you mentioned (avoiding context
    sharing, preventing collections from growing, etc.)
    have a pretty big impact on productivity. Having to
    do that extra work doesn't make the Java API very
    usable IMHO.
    I believe that a certain discipline is needed in writing real-time code anyway, and checking for the above issues is just part of that. Minimizing sharing should be a goal regardless simply because of contention issues and priority inversion issues. Thinking about how to communicate between NHRTs and the rest of the application is something that should always be undertaken.
    Javolution, on the other hand,
    eliminates most of those steps.
    If it works well for you then go for it. Use the tools that best suit the job.

    Though I am cautious when data structures try to "alleviate GC pressure" as they may be making assumptions about how allocation and GC works that don't necessarily hold on a given implementation.

    Cheers,
    David Holmes

    Message was edited by:
    davidholmes - fixed typo