[coyotos-dev] Sleep for interval

[Jonathan S. Shapiro]

I now want to switch my attention to "sleep for interval". This is
something that should be implemented by the kernel, mainly because the
kernel already has to implement an interval timer anyway in order to
implement scheduling.

I assume that the system implementation has some known (or measurable)
hardware interval clock rate, and that the ratio between this rate and
microseconds can be computed. I further assume that the external
interface of the kernel sleep capability will express intervals in
multiples of microsecond intervals.

  If there is a more appropriate unit, please say so, but I'm going to
  continue with microseconds for the sake of descriptive clarity.

Implementation:

In contrast to all other kernel capabilities, which are always
receiving, the definition of the sleep object is that it will remain in
a non-receiving state until the invoker's specified interval has run
out. This has three consequences:

  1. Sleep always happens to the invoker. Process A cannot place process
     B onto a kernel sleep queue.
  2. A non-blocking invocation on the sleep capability always returns
     immediately.

The main question here is: what should be done if a checkpoint/restart
occurs? It seems to me that there are several cases to consider:

  1. In systems having no persistent state at all, there is no problem,
     because the sleep will not be re-issued on restart.

  2. In systems having state but no wall clock, we can define a sequence
     of monotonically increasing epochs defined by the number of
     checkpoints that have occurred to date. Every system has a restart
     epoch that is defined by the checkpoint epoch from which it was
     resumed. Given two epochs E1 < E2, all time intervals in E1 are
     deemed to have completed when restart epoch E2 begins.

     If this design is adopted, all interval sleeps are terminated by
     restart.

     In the absence of a free-running time source that survives power
     interruption there is no sensible way to determine how much of an
     interval may have passed, so there is no outcome under which a
     re-issued interval can be sensibly interpreted.

  3. In systems having a free-running clock that survives powerdown,
     the possibility exists that we might be able to recover a
     monotonic notion of interval time. This is what the PC people
     unfortunately refer to as a "real time" clock. The important
     property of this clock is that it is free-running and monotonic.
     There is no requirement for the hardware to support human time.

     [Aside: we really want to avoid human time altogether in the
      kernel specification, because my understanding is that UTC has not
      always been monotonic.]

At the moment, my opinion is that (1) is self-evident and more or less
unavoidable; (2) is probably worth implementing in the kernel, and (3)
is something to think about for implementation outside the kernel at a
future time. I observe that if you are willing to sleep across a
checkpoint, you are already accepting a potentially long sleep, and
asking you to do that with the support of a user-level agent does not
seem onerous.

Obviously, this is not a complete solution to all possible forms of
interval time, but what to people think of it as a starting point?
-- 
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org