This content has been marked as final. Show 4 replies
Processing groups and cost enforcement are optional facilities in the RTSJ and neither are supported in Java RTS.
For more information on PG's and their role take a look at the real-time programming book(s) and papers by Prof Andy Wellings at the University of York in the UK. Also google for "sporadic servers" as they were the motivation behind Processing Groups.
Dear David Holmes,
thank you for your reply on my question.
Well, I have already read most of Prof Andy Wellings papers about Servers and Scheduling in RTSJ, as also his book about real-time programming in Java and the book of Peter Dibble.
When mentioned therein, PGPs in RTSJ are mostly treated in a theoretical way, explaining similarly to you they role as sporadic servers in the real-time Java platform.
My problem in understanding the manner of the ProcessingGroupParameters is a more practical one.
If I would like to implement a server for whatever kind of load (aperiodic, sporadic or even periodic tasks), on which amount could I rely on already supported mechanisms by the JVM?
When PGPs contain a cost value, then it is up to me to implement monitoring mechanisms for the contained threads executions and to substract their consumed CPU time from the Server (Processing Group) cost.
E.g. cost monitoring and enforcment for Processing Groups is optional, as it is also for real-time threads.
Real-Time threads have at least a release time, probably a period and a deadline. Their execution is mandated by the PriorityScheduler with the help of the cyclic driver.
Although PGPs also provide the same values as threads, they are not "released" in this sense, and their deadlines are not monitored.
Ordering of thread releases within a group in relation to its "release time" and period, as also the monitoring of their deadlines in relation to the groups overall deadline seems to depend on application logic itself.
This brings me in confusion with the purpose of this class (PGP) since everithing one would need from it must be self-implemented.
Or better: when using a RT-JVM which does not support cost monitoring and enforcement, what is the chance for me to implement a kind of Server using the PGPs, since they are intended for that ?
Sorry for my doubting comments on that, I know that costs and feasibility are optional in RTSJ in order to gain a greater acceptance by JVM vendors,
which otherwise would have to stick with complex implementations of cost monitoring and feasibility algorithms for their JVMs.
I have a common scenario of some applications of different criticality, and processing groups would seem to be the right thing for their scheduling an degradation.
E.g. if an application has consumed up its Server capacity, its threads shall be degraded on a background priority and replenished again on next Server release.
By the way, this is very common scenario which is very often applied in the papers of Prof. Wellings and in which PGPs are heavily involved.
Unfortunatelly, it seems to me impossible to realise it with the current stage of Java RTS, unless I implement a kind of cost monitoring and enforcement.
Here, the only thing I can rely on are the release times, periods and deadlines of real-time threads.
in addition for anyone interested in that topic, I recommend an interesting paper , explaining the role of Processing Groups,
and why they are hard to be provided in a RTSJ implementation.
 +"Processing group parameters in the real-time specification for Java"+, A. J. Wellings and M. S. Kim,
in Proceedings of the 6th international workshop on Java technologies for real-time and embedded systems.
The ProcessingGroupParameters class must be present even if an implementation does not support the use of ProcessingGroups. In such a case the class serves no purpose other than potential "documentation" or for use by application logic alone. If the VM does not support processing groups then you have no means to implement deadline monitoring or cost enforcement yourself. Java RTS does not support processing groups and does not support cost enforcement.