The Distributed RealTime Specification for Java Overview and Status

1
The Distributed Real-Time Specification for
JavaOverview and Status

• Ray Clark, E. Douglas Jensen, Doug Wells, Andy
  Wellings
• jensen_at_real-time.org
• http//www.real-time.org, http//www.drtsj.org
• 11/11/02

2
The Distributed Real-Time Specification for Java
Proposal

• Java Specification Request (JSR) 50 in Suns Java
  Community Process
• Spec Lead E. Douglas Jensen, MITRE
• Extend the Real-Time Specification for Java
  (RTSJ) to distributed systems
• Adhere to the Java programming mindset and
  naturally extend existing facilities where
  appropriate
• Enhance Javas Remote Method Invocation (RMI)
  facility to support application-specific
  predictability of end-to-end timeliness
• Not supposed to be a research project, but much
  of the necessary work has never been done before

3
JSR-50 DRTSJ Expert Group

• Leader Doug Jensen (MITRE)
• RTSJ experts
• Greg Bollella (Sun), Doug Locke (TimeSys), David
  Hardin (aJile RT Java products on a chip), Ben
  Brosgol (AdaCore)
• RMI experts Ann Wollrath (Sun), Esmond Pitt
• Industry and Defense
• Jason Lawson (AFRL), Kirk Rheinholtz (NASA JPL),
  Dave Sharp (Boeing), Gautham Thaker (Lockheed
  Martin), Doug Wells (The Open Group), Franco
  Travostino (Nortel Networks), Ray Clark (MITRE),
  Hiroaki Hashimukai (Yamatake), Paul LaCrosse
  (LaCrosse Consulting), Gary Silvers (IBM)
• Academics Andy Wellings (U of York), Raj
  Rajkumar (CMU)
• Real-Time CORBA experts
• Bill Beckwith (OIS ORBExpress), Chris Gill
  (WUStL TAO ORB)

4
The writers and prospective users of the
DRTSJneed to agree on some basic concepts and
terms

• First, it is necessary to summarize what
• real-time
• distributed
• distributed real-time
• mean in the context of the DRTSJ
• All three terms are frequently used with widely
  different, usually imprecise, meanings
• Without a common conceptual understanding and
  corresponding lexicon, it would be very difficult
  for
• the JSR-50 specification writers to write the
  DRTSJ
• prospective users to assess it with respect to
  their requirements

5
A system at a given layer is distributed in
terms of multi-node behaviors

• For the DRTSJ, the term distributed system refers
  to
• a computing system layer that includes at least
  one programming model based on there being
  execution entities that exhibit graphs of
  multi-node behaviors including (but not limited
  to)
• control flow, such as RPC, remote method
  invocations
• data flow, such as publish/subscribe
• asynchronous message-passing
• mobile code
• autonomous agents
• virtual shared memory, including tuple spaces

6
The DRTSJ is focused on programming models
forRTSJ-compliant distributed object systems

• The DRTSJ is focused on distributed object
  systems (DOS)
• a DOS facilitates programmers dealing with remote
  objects in addition to local ones
• typically control flow programming models
• JavaRMI and CORBA are good examples
• The DRTSJ includes programming models for
  real-time Java (RTSJ-compliant) distributed
  object systems
• To the extent that the DRTSJ does not support
  other models (including Javas mobile objects)
  effectively, we relegate them to a prospective
  subsequent distributed real-time Java JSR

7
The DRTSJs scalability is intended
forintra-enterprise environments

• A distributed object system requires a
  well-defined architecture with stable interfaces
  between components and some system-wide
  agreements on infrastructure
• In a real-time distributed object system, that
  agreement includes the semantics of timeliness
  and sufficiently synchronized global physical
  time
• Typically, such systems are found inside an
  enterprise it is difficult to create the
  technical agreements and coordination needed to
  build a distributed object system among
  enterprises
• This is consistent with the current normal
  deployment of distributed real-time computing
  systems in military platforms, factories,
  industrial equipment, etc.

8
A system operates in real-time to the degree that
it satisfies its time constraints

• Many (perhaps most) systems include actions with
  completion time constraints e.g., deadlines
• These actions may be at any levels of an
  enterprise, from sensor to CEO
• A system (at any given level) operates in
  real-time to the degree that its action time
  constraints are satisfied
• how optimal the set of completion times are, with
  respect to a sequencing optimality criterion
  e.g.,
• meet all hard deadlines
• minimize the mean tardiness
• how predictable that optimality is, with respect
  to a predictability model e.g.,
• binary determinism
• coefficient of variation

9
Programmers should be able to express actual
time constraints

• The most natural approach is for application
  programmers to have constructs for directly
  specifying actual execution entity (say, thread)
  completion time constraints that are inherent in
  the application e.g., BeginTimeConstraint ,
  EndTimeConstraint
• Time constraints must be interpreted uniformly in
  a distributed real-time system, so they require
  that the system have global physical time that is
  appropriately well synchronized at each node

10
A time constraint is a lexically scoped
attribute of a thread
thread
thread is non-real-time
scheduling event
begin_time_constraint (t)
tc scope
thread is real-time
scheduling event
end_time_constraint
thread is non-real-time
code
11
Most system software provides only prioritiesand
application programmers must interpret them

• Real-time, and particularly distributed
  real-time, computing systems that provide for
  using actual time constraints are the exception
• The usual practice is that system software (e.g.,
  ORB, JVM, OS) provides only a priority mechanism,
  
• and the programmers are required to establish
  the priority semantics by mapping time
  constraints (such as deadlines) onto them
• Rarely, the system software provides or
  facilitates this mapping e.g., Real-Time CORBA

12
Such mappings are complicated in all the but
simplest, smallest, and least dynamic systems

• Priority assignments for multi-node behaviors
  require global knowledge of all other priority
  assignments on all nodes that the multi-node
  behaviors could involve (whereas time constraints
  are local knowledge)
• The granularity of time constraints is typically
  much finer than that of priority ranges
• Priority ranges supported by a system's
  constituent OS's, JVM's, ORB's, etc. may be
  different, in which case there must be a mapping
  between each pair
• Semantics are associated with priorities by the
  users, the system and application software, and
  the hardware not always (or even usually)
  entirely coherently

13
Priorities in real-time systems have timeliness
semantics and are used to achieve timeliness

• High degrees of priority compliance are not a
  differentiating characteristic of real-time
  systems (e.g., OS's, ORB's, JVM's)
• they can be as valuable in non-real-time systems
  as in real-time ones
• The differentiation between real-time and
  non-real-time priority systems arises from
  real-time ones
• having priority semantics based on application
  time constraints
• and employing the priorities to resolve resource
  contention with the objective of improving system
  timeliness properties

14
The DRTSJ supports the RTSJs default priority
discipline, plus arbitrary other disciplines

• The RTSJ is oriented toward priority-based
  sequencing, but seeks to support some other
  disciplines
• So the DRTSJ includes conformance points for
• the most common case of priority-based sequencing
• arbitrary sequencing disciplines for more complex
  systems (requires extensions to the RTSJ)
  including
• deadline-based using the RTSJs parameters
• time/utility functions

15
Real-time distributed systems are distinguished
by having end-to-end timeliness properties

• Distributed systems have multi-node properties
  that must be maintained
• Distributed systems are real-time ones to the
  degree that they include multi-node behaviors
  having timeliness properties
• with the same two dimensions as real-time
  centralized systems
• how optimally application time constraints are
  satisfied, with respect to a given optimality
  criterion
• how predictable that optimality is, with respect
  to a given predictability model
• on an end-to-end basis

16
An execution entitys multi-node behavior may
have end-to-end time constraints
17
Example real-time multi-node behavior battle
management sensor-to-shooter chain
18
Example real-time multi-node behavior battle
management sensor-to-shooter chain
From An Example Real-Time Command, Control and
Battle Management Application for Alpha (1988)
19
Example real-time multi-node behaviorAffordable
Moving Surface Target Engagement
1 second deadline for sensor to tracker to
shooter 4 - 6 Hz update rate to shooter
20
Multi-node timeliness must be acceptable under
the current circumstances

• The defining characteristic of any real-time
  distributed computing system is that the
  timeliness properties of each execution entitys
  multi-node behavior
• on each individual node it involves
• and collectively end-to-end on all nodes it
  currently involves
• are acceptable to that entity and the system
  under the current circumstances
• most familiar
• minimize number and duration of priority
  inversions
• always meet all hard deadlines
• other examples
• minimize mean (or maximum) tardiness
• maximize accrued utility

21
The current circumstances are generally
dynamic to some degree

• The current circumstances include
• the latency characteristics of the underlying
  infrastructure (node OSs, network, etc.)
• the attributes of the system load
• the attributes of the execution environment
• All those circumstances are known and controlled
  á priori in static distributed real-time
  computing systems, notably including hard
  real-time ones
• But in general, not all of those circumstances
  are (or can be) known and controlled á priori
• the system is dynamic to the degree that is the
  case
• and must be adaptive

22
The DRTSJ is intended for the whole range of
dynamic systems including the static special case

• The RTSJ is oriented toward general non-static
  systems,
• although it has been demonstrated to
  successfully support static hard real-time
  computing
• Similarly, the DRTSJ is oriented toward the
  general case of arbitrarily dynamic distributed
  real-time computing systems,
• although we expect it to also be capable of
  supporting the special case of static hard
  real-time ones

23
Multi-node end-to-end properties require
visibility in space and time of certain state

• End-to-end timeliness of multi-node behaviors
  necessitates that each behavior's timeliness
  parameters (e.g., including its priority or
  deadline) be
• known, with the same semantics, at each node the
  behavior currently involves
• and used there for resource management
  i.e.,resolving contention for shared resources
  (e.g., sequencing processors, locks, etc.)

24
Visibility in space and time of state
parameterscan be static or dynamic

• Those nodes can either know these parameters a'
  priori, or obtain them dynamically
• For example, timeliness parameters could be known
  a' priori if the behavior at a node is
  time-constrained by the nature (e.g., physical
  properties) of the application, independent of
  any time constraints on the behavior at other
  nodes
• More commonly, the timeliness parameters must be
  propagated as a behavior involves other nodes
• Distributed systems that use priorities for
  resource access (e.g., execution) eligibility may
  propagate priority as a distributed behavior
  involves a remote node
• Acquiring, propagating, depositing, and employing
  this information should be done transparently to
  the application programmers

25
End-to-end properties depend on eligibility
compliance of resource management

• End-to-end timeliness of multi-node behaviors can
  be achieved to a degree highly dependent on the
  extent of eligibility compliance
• the extent to which those parameters are
  consistently employed at each such node, and by
  the network connecting them, for resolving
  contention for physical and logical resources
  (e.g., processor and communication path
  scheduling, lock dequeuing, etc.)
• Realistically, especially given COTS software and
  hardware products, not all resource management
  will employ these parameters or employ them
  consistently
• so there will be some number and durations of
  end-to-end timeliness anomalies (e.g.,
  eligibility inversions, such as the special case
  of distributed priority inversion)

26
Extend the RTSJ for distributed systems

• One of the least well understood problems
• distributed version of RTSJs scoped memory
  (maintaining referential integrity without
  garbage collection)
• Some of the problems we understand better
• global thread IDs
• distributed events
• global physical time, serializable time classes
• remote interfaces for class definitions
• serializable interfaces for class definitions

27
Enhance Javas RMI for real-time DRTSJ
programming model conformance points
Java RMI No Distributed Real-Time Capabilities
Level 1 Piecemeal Distributed Real-Time
Programming
Level 2 End-to-End Real-Time Programming
28
Enhance Javas RMI for real-timeDRTSJ
Conformance Point 1

• Oriented toward traditional real-time
  programming-in-the-small presumes systems small
  and simple enough to understand and manage
  resources for as a whole
• Real-Time RMI
• RTSJ objects that can be accessed remotely are
  identified via a real-time remote interface
• passes timeliness parameters hop-by-hop to RTSJ
  remote objects
• Employs RTSJs SchedulingParameters and
  ReleaseParameters (defaults to priorities etc.)
• No global physical time (i.e., synchronized local
  clocks)
• Real-Time Java Remote Method Protocol (RT-JRMP)
• Backward compatible with regular RMI
• No changes to RTSJ and RTSJVM

29
Enhance Javas RMI for real-timeDRTSJ
Conformance Point 1

• Application programmers must deal with thread
  synchronization issues (the proxy thread is not
  the same thread as the client thread) e.g.,
• a client thread calls a synchronized method in
  Object A, which calls a remote method in Object B
  the called method in Object B then directly (or
  indirectly) calls a synchronized method in Object
  A, causing deadlock
• the data read by the second call to Object A will
  not be the data that is read by the original call
  in Object A
• Crash failures only server informed of client
  failures via ATC or AEH
• None of the RTSJ class definitions define remote
  interfaces so they can offer no remote services
• Other than AIE, none of the classes implement the
  Serializable interface, and consequently objects
  of these classes cannot be passed across a remote
  interface

30
Enhance Javas RMI for real-timeDRTSJ optional
Conformance Point 2

• Oriented toward real-time programming-in-the-large
  presumes systems too complex to understand and
  manage resources for as a whole, because of
  interacting multiple properties
• Distributed Real-Time RMI
• Distributed Threads, including integrity
  maintenance
• passes timeliness parameters even with legacy
  Java objects
• solves thread synchronization issues
• Supports arbitrary scheduling disciplines
• Supports RT-JRMP and IIOP
• Requires extensions to the RTSJ, RTSJVM, RMI, and
  RTC2
• Backward compatible with the RTSJ, RTSJVM, and
  RMI
• Non-goal interoperability of different
  implementations

31
Conventional distributed object models dont
retain local semantics on remote invocations

• For a local invocation in most distributed object
  systems
• there is only one thread
• it retains its identity and properties (e.g.,
  timeliness) whichever method it executes
• Conventional remote method invocation (and RPC)
  involve
• separate schedulable entities on each node
  (client, servant)
• which communicate with each other
• That
• doesnt accurately reflect the programmers
  intention of control flow
• spanning objects, and thus physical nodes
• maintaining end-to-end properties
• (not an attempt to have total location-transparen
  cy)

32
A Distributed Thread is an end-to-end control
flow abstraction

• A distributed thread is a logically distinct and
  identifiable locus of control flow movement,
  within and among objects (and thus nodes)
• A distributed thread executes a remote method,
  like a local one, directly itself by extending
  and retracting itself between objects and nodes
• A distributed thread always has exactly one
  execution point (head) in the whole system
• control flow can be forked by creating or
  awakening other distributed threads
• The distributed thread (not a local thread) is
  the schedulable entity
• A program may consist of multiple concurrent
  distributable threads

33
A Distributed Thread is an end-to-end control
flow abstraction
dthread 1
dthread 2
dthread 3
Object A
Object B
Object C
Object D
34
InteroperabilityJava Thread Invoking...
Distributed Real-time Remote Interface
Real-time Remote Interface
Remote Interface
Default timing properties used by distributed RT
RMI Server proxy is a new distributed
thread No AIE
Default timing properties used by RT RMI Server
proxy is RTSJ real-time thread No AIE
Defined by RMI Server
proxy is a standard Java thread No AIE
35
InteroperabilityJava RealtimeThread Invoking...
Distributed Real-time Remote Interface
Real-time Remote Interface
Remote Interface
Client timing properties used by distributed RT
RMI Server proxy is a new distributed
threadAIE propagated through RT RMI then to the
head of the distributed thread
Client timing properties used by RT RMI Server
proxy is RTSJ real-time thread with inherited
scheduling parametersAIE propagated through RT
RMI
Defined by RMI Server
proxy is a standard Java threadNo AIE
propagated
36
InteroperabilityJava DistributedRealtimeThread
Invoking...
Distributed Real-time Remote Interface
Real-time Remote Interface
Remote Interface
Defined by RMI Server
proxy is a standard Java threadNo AIE
propagated
Client timing properties used by distributed RT
RMI Server proxy is a new segment of a
distributed threadAIE propagated to the head
of the distributed thread
Client timing properties used by RT RMI Server
proxy is RTSJ real-time thread with inherited
scheduling parametersAIE propagated through RT
RMI
37
What is the relationship betweenDRTSJ and
Real-Time CORBA?

• What are the possible relationships between DRTSJ
  and Real-Time CORBA 1 2 ?
• DRTSJ RTSJ RTC 1 or 2 ?
• RTC 1 or 2 as a component of RT-RMI ?
• We strongly desire to make it attractive for
  DRTSJ implementations to be constructed using
  Real-Time CORBA implementations
• that desire is shared by the JCP Executive
  Committee(s)

38
DRTSJ and Real-Time CORBAa task force report to
the Expert Group

• Composition of RTSJ and RTC 1
• option 1 exposing RTC interfaces
• option 2 using RTC 1 within RT RMI facility
• Composition of RTSJ and RTC 2
• options 1 and 2 again considered
• coexistence and coordination of multiple
  schedulers
• coexistence and coordination of
  distributed/distributable threads
• Advanced features that are not in these
  compositions
• distributed thread integrity
• support for RTSJ-introduced non-heap memory

39
History Timeline for the DRTSJ

• JSR Approval 26 Mar, 2000
• CAFE 11 Apr,
  2000
• Expert Group Formed 14 Aug, 2000
• First Draft of Specification
• Community Review
• Public Review
• Proposed Final Draft no later than
  9/2003
• Final Approval

CAFE Call For Experts
40
Current DRTSJ Status

• Accomplishments
• general Expert Group consensus on scope and goals
• documented in multiple publications
• basic programming model understood
• relationship to RT CORBA approaching completion
• experiments and preliminary Reference
  Implementation work enable investigation of Level
  1 issues

41
DRTSJ Reference Implementation and experiments

• Goals
• Produce Reference Implementation
• Gain experience with various Java platforms and
  RMI implementations
• Understand structure of RMI implementations

42
DRTSJ Reference Implementation and experiments

• Activities
• Examined candidate JVMs and RMIs
• Experimented with candidate elements of RT RMI
  solutions
• RTSJ Reference Implementation
• Kaffe and Gnu Classpath RMI facilities
• Produced a standalone rmic to generate customized
  RT RMI stubs and/or skeletons
• Producing proto-RT RMI (DRTSJ CP 1)
• passes identity and scheduling parameters
• utilizes RealtimeThreads in RealtimeRemote
  infrastructure and implementations

43
A Ballsorting Apparatus
44
The Physics of Ballsorting
distance
0 ( t 0, v v0 )
sB ( t tB )
sF ( t tF )
45
DRTSJ technology demonstrationProto-Conformance
Point 1 distributed system
Demonstration Components - Pentium-class PCs -
Operating System Linux (Debian, Red Hat) - RTSJ
Java Platform TimeSys Reference Implementation -
RT-RMI (experimental) MITRE-modified GNU
Classpath (originally contributed by
Transvirtual)
46
DRTSJ FY03 (10/02 9/03) Work Plan

• Complete definition of Level 2 features
• Implement Level 2 features in Reference
  Implementation
• Develop Technology Compatibility Kit (test suite)
• Conduct formal reviews and feedback
• Demonstrations e.g.,
• AWACS ATD adaptive tracker
• AWACS NMT/Step 40/45 infrastructure
• partial failures have not been detected or
  detected in a timely manner
• Evangelism
• develop materials and espouse use of DRTSJ
• Technology transfer
• work with vendors of potential products

47
Selected DRTSJ References

• Jensen, Wellings, and Wells, The Distributed
  Real-Time Specification for Java A Status
  Report, Proc. Embedded Systems Conference/San
  Francisco, Sept. 2002
• Wellings, Clark, Jensen, and Wells, A Framework
  for Integrating the Real-Time Specification for
  Java and Javas Remote Method Invocation, Proc.
  IEEE ISORC, April 2002
• Jensen, The Distributed Real-Time Specification
  for Java An Initial Proposal, Journal of
  Computer Systems Science and Engineering, March
  2001
• All documents available at http//www.real-time.or
  g/preview/referenced_documents.htm
• DRTSJ web site http//www.drtsj.org

48
Backups