JSR-282 SI 104.2
------------------------------------------------

Summary
---------------------

Clean up behavior of AsyncEvent and RealtimeThread where a handler
is added or is started after its start time.

Specification References
---------------------

AsyncEvent, RealtimeThread, PeriodicParameters

Problem being Addressed
---------------------

The current specification requires a periodic thread or periodic event
handler, when an absolute time is specified in its scheduling
parameters, to start immediately when started or added after its given
start time.  This behavior does not make sense, since either the system
has started before intended or tasks that where intended to have a given
phase relationship will no longer have that relationship.  The later
could result in too many tasks being scheduled at the same time.  In
general, there is a discontinuity in the timing behavior of periodic SO
with regard to an absolute start time and the time when the SO actually
starts.

Proposed Solution Summary
---------------------

Constructors are added to PeriodicParameters to provide two new
scheduling paradigma: either an IllegalArgumentException is thrown when
the SO is activated (started or a handler is added) after its start time
or the SO is started at t = start + (n * period) for the minimal value
of n where t is after the time the SO is activated.  Which of these
behaviors is used is determined by constructor parameters.

Semantics
---------------------

Add the following two constructors to PeriodicParameters.

PeriodicParameters(AbsoluteTime start, RelativeTime period, boolean strict);

Create a PeriodicParameters object with the given start time and
period.

PeriodicParameters(AbsoluteTime start, RelativeTime period, boolean strict,
                   RelativeTime cost, RelativeTime deadline,
                   AsyncEventHandler overrunHandler,
                   AsyncEventHandler missHandler);

Create a PeriodicParameters object with the given start time, period,
cost, deadline, overrunHandler, and missHandler.

Add the following two constructors to PeriodicTimer.

PeriodicTimer(AbsoluteTime start, RelativeTime interval, boolean strict,
              AsyncEventHandler handler);

Create an instance of PeriodicTimer that executes its fire method periodically.

PeriodicTimer(AbsoluteTime start, RelativeTime interval, boolean strict,
              Clock clock, AsyncEventHandler handler);

Create an instance of PeriodicTimer that executes its fire method periodically.

In all cases, when strict is true, Thread.start(), PeridicTimer.start(),
and PeriodicTimer.start(true) throw an IllegalArgumentException when the
start time has passed.  Also when the start time has passes and strict
is false, the start time is delayed until time smallest value of t after
start, where t = start + (n * period).  This would ensure that the phase
relationships between different start times would be preserved even when
any of the start times has passed.


Discussion Points
---------------------

Is a boolean enough?

Should there be a way of querying and changing these parameters?

Should reschedule be adapted as well?

   reschedule(AbsoluteTime new, boolean strict);

Compatibility Issues
---------------------

None