This content has been marked as final. Show 3 replies
One of the challenges when using the RTSJ is the lackThere 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.
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.
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.
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)
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 thatNo that wasn't what I said.
doesn't exist, since one can just use the standard
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 contextI 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.
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
Javolution, on the other hand,If it works well for you then go for it. Use the tools that best suit the job.
eliminates most of those steps.
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.
Message was edited by:
davidholmes - fixed typo