Resource Management Discussion: Led by Tucker Taft, Intermetrics, An AverStar Company

-Scheduling and Priorities

-Coordination and Synchronization

Goal: Portability of RT components
Derived Requirement: Well-defined API with guarantees on all language features

Goal: Implementable on existing RTOSs
Derived Requirement: Does not rely on "exotic" underlying mechanisms.
Discussion: Most are priority based Most support some kind of priority "boosting" (priority inheritance, priority ceiling) Priority based mechanisms most natural choice for RT Java. Requiring synchronized/wait/notify to "work right" is not a major implementation burden.
   

Goal: Support use of components as "black boxes", including on the same thread
Derived Requirement: Ability to impose space/time/etc. limits, in a scoped manner, from the outside; on "standard" Java features too.

Derived Requirement: Existing Java features shall "work right" including:
    -synchronized (bounded priority inversion)
    -wait/notify (priority queuing)
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.

Goal: Support multiple scheduling policies/models
Derived Requirement: Provide support for user-defined scheduling policy control and flexible underlying mechanism.

[Semi] Open Issues: Need to standardize various "utility" synchronization classes, such as: semaphore, barrier, message queue, r/w lock,..)?  Justification: Interoperability with native call.  Initial Recommendation: Not a requirements.  Issue Answer: Maybe,  to solve specific problems.
 

Scheduling Policy Manager:  This concept was presented by Tucker Taft.  The consensus of the group is that it is an idea deserving further discussion.