[coyotos-dev] Sleep for interval

[Valerio Bellizzomi]

On 22/09/2007, at 16.40, Jonathan S. Shapiro wrote:

>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.

Can nanosec or picosec be achieved on PC hardware ?

Go to http://en.wikipedia.org/wiki/System_time, notice the table at
Retrieving system time, in particular notice the columns Resolution and
Epoch. These suggest that there isn't any standard at all. So, how do we
choose a resolution? I don't know.

>
>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.

I think it is ok for me that 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.

>From http://en.wikipedia.org/wiki/Real_Time_Clock :

Most RTCs use a crystal oscillator ....... In many cases the oscillator's
frequency is 32.768 kHz ........... the frequency is exactly 2E15 cycles
per second, which is a convenient rate to use with simple binary counter
circuits.

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

The joys of leap seconds.

>
>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?

It *is* a starting point !

>-- 
>Jonathan S. Shapiro
>Managing Director
>The EROS Group, LLC
>www.coyotos.org, www.eros-os.org
>
>_______________________________________________
>coyotos-dev mailing list
>coyotos-dev at smtp.coyotos.org
>http://www.coyotos.org/mailman/listinfo/coyotos-dev