Vladimir.Nikolov wrote:Well it has to be supported by that implementation of the RTSJ. Howe that is done - ie whether it requires OS support - depends on that VM, the OS and the actual scheduling policy.
That means, that a scheduling policy different to PriorityScheduler can only be assigned to a Schedulable object if it is supported by the OS and the JVM?
It also seems that at the current state of the art the PriorityScheduler representative within the JVM is intended only for manipulating a feasibility set of Schedulable objects (supporting online feasibility analysis)?The RTSJ scheduling framework provides support for feasibility analysis by defining the admission control methods eg setXXXIfFeasible. However the RTSJ does not, and can not, mandate any non-trivial feasibility algorithm because in simple terms no such general algorithms exist. There are some static feasibility tests in the literature and you could apply those offline to your application (assuming you can find the values of all the "magic" numbers in such formulae - which is generally not the case). At present the RTSJ doesn't support even these simple feasibility tests because blocking-time is not recorded in the release parameters - something being addressed in RTSJ 1.1. In any case unless there is a pluggable framework for feasibility tests it would be a waste of time for VMs to implement them given they can (more) easily be done offline using other tools.
However, since user-defined scheduling is not intended by the specification, applications have to rely on the feasibility analysis based on the underlying/supported scheduling mechanisms.
Thus, in the current Java RTS implementation this would be the "default" feasibility mechanism based on the PriorityScheduler.
Unfortunatelly I can not figure out the need of maintaining a feasibility set, since feasibility, as specified for the PriorityScheduler, is a simple asumption that we have "an adequatly fast machine to handle the periodic and sporadic load"?
I actually assumed that feasibility analysis performs real cost budgeting taking into account deadlines and so on, but it seems to be specified simply to make a negative statement always when aperiodic tasks are involved ?
In "Getting More Flexible Scheduling in the RTSJ" Wellings and Zerzelidis propose some (more or less) "minor" extensions to the RTSJ API in order to enable hierarchical scheduling within the fixed priority framework.If there is ever a RTSJ 2.0 then more sophisticated scheduling support is one of the items on the wishlist. But there's no guarantee there ever will be a RTSJ 2.0
Since Andy Wellings is a member of the RTSJ Technical Interpretation Committee, is there any attempt to evolve the specification in a similar direction as described above, in order to support more flexible scheduling mechanisms and feasibility analysis?