Time and Timers
Sasu Tarkoma
sasu.tarkoma@cs.helsinki.fi
Real-Time Linux and Java Seminar
University of Helsinki
Department of Computer Science
Abstract
The Real-Time Specification for Java (RTSJ) extends the standard Java language and
virtual machine to meet the requirements of real-time applications. The current Java
language lacks support for sub-millisecond granularity and real-time timers. RTSJ
defines an abstraction of time that is used throughout the specification and supports
both absolute time and relative time. This paper examines the time and timer
extensions specified in RTSJ.
1. Introduction
This paper presents the parts of the Real-Time Specification for Java (RTSJ)
pertaining to time and timers [Sun01]. RTSJ is a specification that aims to extend the
standard Java language [GJS96] for the requirements of the real-time domain. RTSJ
provides the semantics and the minimum requirements for different implementations.
The benefits of a real-time Java standard include portability, lower development costs,
enhanced network connectivity and increased functionality of real-time systems.
Historically, RTSJ originally consisted of three different attempts to create real-time
Java programming language and virtual machine. The three groups that were working
on real-time Java were from IBM, Sun and NewMonics, and their output was the
document titled Requirements for Real-Time Extensions to Java (RTTEJ) [NIS99].
The requirements group identified areas where the standard Java Language
specification and Java Virtual Machine (JVM) are unsuitable for real-time
applications, and which needed improvements. However, their aim was to keep the
extensions to the Java language backwards compatible.
A real-time Java
implementation should be capable of executing standard Java applications with
standard Java guarantees and real-time components with additional semantic
guarantees.
The requirements document in turn was the starting point for the Java Expert group
[RTJ01] and the RTSJ specification, more specifically the JSR-000001. The RealTime Expert Group worked to define new mechanisms in order to support the
development of real-time applications in Java and addressed semantic issues that were
too vague for the real-time domain. Currently, the Real-Time for Java Expert Group
has the responsibility for specifying real-time extensions to the Java language and the
Java virtual machine specifications.
This paper examines the timing and time extensions specified in the RTSJ
specification. Time is vital for real-time systems, where timeliness needs to be
monitored and enforced. The real-time Java specification mandates consistent timing
behaviour.
The standard Java language supports timing using the Date and Calendar classes,
which have millisecond granularity. Clearly, this is not enough for real-time domains,
where low-latency applications may require sub-millisecond accuracy. In addition,
the standard Java language does not have a very good support for timers, which need
to be done using implementation specific means or using the Timer-class provided by
the JDK 1.3 API [Sun01a]. However, the Timer from JDK 1.3 does not have any
real-time guarantees.
The RTSJ specification supports abstraction of time with nanosecond granularity that
is used throughout the interfaces. This paper is structured as follows: Section 2
presents the time classes defined in the RTSJ specification and Section 3 examines
timers. Finally, a summary is presented in Section 4.
2. Time

Time is the essence of real-time systems and the basic requirement of the RTSJ
specification was that the real-time Java implementation must be able to express
absolute time with sub-millisecond precision, for example with nanosecond
granularity. This precision may vary with hardware present on the system. In
addition to absolute time, relative time is also necessary in order to support various
time-based metaphors and temporal constraints; for example deadline-based
scheduling. Accurate and high timer resolutions are needed by various real-time
entities: threads, drivers and system components such as schedulers.
The RTSJ specifies that all time objects must maintain nanosecond precision, which
at the implementation level consists of the millisecond and nanosecond part.
Backwards compatibility is being maintained by having the millisecond component
(which maps to existing Java time classes such as Date). The specification also
mandates that time objects must be constructed from other time objects or from time
values, and the addition and subtraction of both objects and time values and
comparison (using the Comparable-interface) must be supported.
The time extensions are realized in the following classes: HighResolutionTime,
AbsoluteTime, RelativeTime and RationalTime. The HighResolutionTime is an
abstract class that is subclassed by the other three time related classes and not
instantiable (figure 1). The actual time in all these time-related classes is represented
using a compound form with 64-bit millisecond and 32-bit nanosecond components.
The time objects are convertible to Date objects using either milliseconds or the
getDate()-method in the AbsoluteTime-class. However, application programmers
need to take into account that the time related classes are not thread-safe, and provide
thread-safe modifications in their subclasses.
The AbsoluteTime class encapsulates the time relative to midnight January 1,1970
GMT. This representation is compatible with the standard Java representation of an
absolute time in the Date class. RelativeTime represents a point in time that is relative
to some other time value, usually relative to now. In addition to the two basic time
classes, a new class of RationalTime imposes a number of occurrences to an interval
of relative time. Any method that accepts the class RationalTime(x,y) as a parameter
must guarantee that the activity occurs exactly x times in every y milliseconds. The
RationalTime expresses a frequency by a numerator of type long and a denominator
of type RelativeTime. If given as a parameter to constructors or methods the activity
occurs for frequency times every interval.
public abstract
HighResolutionTime
implements
java.lang.Comparable
RelativeTime
extends HighResolutionTime
AbsoluteTime
extends HighResolutionTime
RationalTime
extends RelativeTime
Figure 1 Relationships between the time classes in the RTSJ specification.
Example 1: PeriodicTimer is given RationalTime of (5,100). The system guarantees
that the timer will fire exactly 5 times every 100 milliseconds. The time between
firings may be adjusted.
Example 2: We construct an absolute time of now without the nanosecond
component and add 500 nanoseconds using the RelativeTime-class.
AbsoluteTime at = new AbsoluteTime(System.currentTimeMillis(), 0);
at.add(new RelativeTime(0,500));
3. Timers
This section examines timers in the RTSJ specification. Timers are based on
asynchronous events, which are triggered either once or periodically using an
appropriate clock. The clock may be a simulation clock, real-time clock or some other
type of clock.
3.1 Asynchronous Events
RTSJ extends the standard Java support for asynchronous events using two classes:
AsyncEvent, which is something that can happen, for example a POSIX-signal or a
hardware interrupt; and the AsyncEventHandler-class that consists of the event
handling logic that is triggered by the event. When an event occurs, the fire() method
is called in the event and the associated handleAsyncEvent() method in the
corresponding AsyncEventHandler is scheduled. AsyncEvent handles the unblocking
of handlers when an event is fired, and maintains the set of handlers for a particular
event. The AsyncEventHandler class implements the runnable-interface and supports
several attribute classes that refine its execution: ReleaseParameters,
SchedulingParameters and MemoryParameters. Similar to threads, the event handlers
are also subject to scheduling and scheduling parameters.
3.2 Clocks
The clock object represents time and is provided by the implementation. Clocks run
from the past, through the present, into the future and they know the concept of
“now”, which is provided by the Clock.getTime()-method.
Timers are based on
Clock-classes and they support and report a set of timer resolutions and can have
events queued to be fired when the activation time is reached.
Clocks can be
subclassed for various types of clocks, such as simulation-time clocks, real-time
clocks and user-time clocks.
Clocks can be also used as a resource allocation strategy. Clocks may have different
granularities and they update their queues based on these granularities. For example;
we have a periodic event that should be noticed within plus or minus 10 seconds of
the actual time the event should occur, and for another event this time is 10
microseconds. Now, extra overhead is introduced if we use a clock object with 10microsecond granularity for checking the queue for both events. An application could
have two instances of PeriodicTimer and two clocks with different granularities; the
first one checks its queue every 10 microseconds and the second clock checks the
queue only every 10 seconds. This kind of approach reduces the queue management
overhead of the accurate clock.
3.3 Timers
A Timer is a timed event based on a given clock. The timer class is a specialized
form of an AsyncEvent that provides the interface and the underlying implementation
for the concrete timer implementations. The Timer represents an event whose
occurrence is driven by an associated Clock class.
RTSJ specifies two forms of timers, the OneShotTimer and the PeriodTimer classes
(figure 2). OneShotTimer is triggered exactly once, and PeriodicTimer is triggered at
recurrent intervals. The PeriodicTimer accepts either RelativeTime or RationalTime,
and in the case of the latter option the system needs to provide a best effort to perform
any necessary corrections to maintain the frequency.
Timers take several parameters: the time to fire the event, optionally a Clock object
and an AsyncEventHandler that should handle the event upon firing. Timers can also
be queried the time (AbsoluteTime) at which the event will be fired and this time may
also be rescheduled. All timer objects disabled by default and need to be started using
the start()-method.
public class AsyncEvent
public abstract class Timer
extends AsyncEvent
public abstract Clock
public PeriodicTimer
extends Timer
public OneShotTimer
extends Timer
Figure 2 Diagram of the Timer related classes in RTSJ.
Timer Example:
We create a new periodic timer that starts 200 ms relative to now and has a period of
200 ms.
PeriodicTimer pt = new PeriodicTimer(new RelativeTime(200,0), new
RelativeTime(200,0),null);
// We get the release parameters from the timer for scheduling
ReleaseParameters rp = pt.createReleaseParameters();
// We give an approximate cost of the handler
rp.setCost(new RelativeTime(20,0));
// We add a handler for the periodic event
pt.addHandler(new AsyncEventHandler(null,rp,null,null,null) {
public void handleAsyncEvent() {
System.out.println(“Timer went off “);
}
});
pt.start();
// start the timer
4. Summary
The standard Java does not support sub-millisecond precision and accurate timing of
events, which are key requirements for a real-time Java language. This paper
presented the RTSJ specification and the extensions to Java pertaining to time and
timers. RTSJ defines a set of time related classes that are used throughout the
specification and uses a backwards-compatible approach for supporting submillisecond granularity. RTSJ specifies four time classes: HighResolutionTime,
AbsoluteTime, RelativeTime and RationalTime, which imposes a number of
occurrences to an interval of relative time. In addition, the Clock-class provides
support different granularities and the foundations for timers. RTSJ defines the
OneShotTimer for events that are triggered exactly once, and the PeriodicTimer for
events that need to be triggered at certain intervals.
5. References
[GJS96] Gosling, Joy and Steele. The Java Language Specification. Addison-Wesley,
1996.
http://java.sun.com/docs/books/jls/html/index.html
[NIS99] NIST. Requirements for Real-time Extensions for the Java Platform. NIST
Special Publication 500-243, 1999.
http://www.nist.gov/itl/div897/ctg/real-time/rt-doc/rtj-final-draft.pdf
[RTJ01] The Real-Time for Java Expert Group homepage, 2001.
http://www.rtj.org
[Sun01] The Real-time for Java Expert Group. The Real-Time Specification for Java
(JSR-000001), 2001.
http://java.sun.com/aboutJava/communityprocess/first/jsr001/rtj.pdf
[Sun01a] Sun Microsystems. Java 2 Platform API Specification, version 1.3, 2001.
http://java.sun.com/j2se/1.3/docs/