Resource Management (RM) Requirements

Working Draft – October 28. 1998 

Example resources include:

• CPU resources raising issues of scheduling, preemption, fairness, time slicing;
• Exclusive access to shared data using synchronized block/method
• Access to restricted (user-defined) resources using wait/notify
• Network routines using RMI

The issues that these requirements address: ED NOTE: This section must be detailed.

• Deadlock avoidance
• Priority inversion
• Budgeting in Advance
• Static availability
• Global vs. local knowledge
• Deadline vs. priority
• Sytem knowledge vs. application knowledge
• Finalizers: how to ensure timeliness and correctness

Utility of Resource Management:

The following capabilities should be supplied or be implementable using the functionality delineated in the specification:

• dead-line based scheduler on top of (or perhaps within) RTJVM. (consensus –agree)
• time-sliced scheduler or periodic scheduler on top (or perhaps within), (optionally make time-slicing a required option.) (consensus –agree)
• resource accounting (especially CPU accounting.) (consensus –agree)
• The ability to determine maximum defferal of event due to primitives that block event. (In what units?) (consensus –open)

ED NOTE: Do the requirements below support these capabilities?
 

RM DR1: The RTJ API must be well-defined with guarantees on all language features. (consensus –agree)

RM DR1 is based on Goal 3: RTJ programs and components should be fully portable regardless of the underlying platform.
   

RM DR 2: Ability to enforce, with notification, event handling and accounting, space/time limits, in a scoped manner, from the outside; on "standard" Java features too. (consensus – agree)

RM DR2 is based on GOAL 9: RTJ should support the use of components as "black boxes"; including on the same thread. (consensus –open)
 
RM DR3: In a real-time context, existing Java features shall "work right" including ‘synchronized’ (bounded priority inversion) and ‘wait/notify’ (priority queuing). (consensus – agree)
Discussion: Any thread created in "scope" of user-defined policy manager is under control of that policy.  Pre-existing thread class priorities might be mapped to "real-time" priorities.

RM DR3 is based on GOAL 9: RTJ should support the use of components as "black boxes"; including on the same thread.
 
 

RM DR 4: RTJ must:

• At least support strict priority-based scheduling, queuing and lock contention. This should apply to existing language features too. (consensus – agree)
• At least support some kind of priority "boosting" (either priority inheritance or priority ceilings). This should apply to existing language features too. (consensus – agree)
• Support dynamic priority changes. (consensus – agree)
• Support ability to propogate a local priority and changes to remote servers (at some level of spec.?). Not just in support of RMI but also in support of user-written communication mechanisms. (consensus – open)
• Support ability to defer asynchronous suspension or disruption when manipulating a data structure.
• Ability to build deadline-based scheduler on top.
• Ability to query to find out the underlying resource availability (non-Java) and handle asynchronous changes to it.

RM DR4 is based on GOAL 8: RTJ should allow resource reservations and should enforce resource budgets. The following resources should be budgeted: CPU time, memory and memory allocation rate. (consensus – agree).

OPEN ISSUES:

1. What to do with ‘schedulability analysis’? Requires more discussion. (Roadmap requirement)