[coyotos-dev] Sleep, wakeup, and persistence

[Sam Mason]

On Fri, Sep 14, 2007 at 02:03:51PM -0400, Jonathan S. Shapiro wrote:
> I want to document a discussion JWA and I had yesterday. This solution
> is probably well known; it just wasn't well known to us.

Our last discussion of time[1] had the kernel stripped of almost all
time related functionality.  Is that still the intention, or have things
changed?

If that is still the case then this is how I see it.

> A process wants to sleep until time X. That is easy if the system keeps
> running until then, but if the system re-starts what happens?
> 
> There are two concerns here:
> 
>   1. The underlying system may not have a monotonically increasing
>      clock. Many embedded systems do not.

What sort of things would these devices have to wait for?  I'd assume
that if they don't have any sort of real time clock, they wouldn't want
to wait until some specific real time---at least not until somehow
determining what the real time is.  They're probably only interested in
sleeping for short amounts of time to keep timeouts and such working.
If that's the case then knowing the real time doesn't matter at all.

There seem to be two use cases to me; that of sleeping for a short
amount of time, and that of sleeping until we reach some specific real
time.  Why not put the first in the kernel, and leave the second up to
userspace to implement.

That way, our embedded system can have the time punched into its
panel/ask some network server and eventually get an answer.  In the
meantime, it can be relying on the kernel for short timeouts.  A PC
would be able to get a good estimate of the real time from its clock
quickly so will be able to start servicing "real time" alarms (for lack
of a better word) quickly.

> To deal with these cases, I believe that the semantics of sleep() must
> be as follows:
> 
>   1. It means "wake me up as soon as possible after time X"
>   2. The caller needs to be able to specify whether a system
>      restart should terminate the sleep.
>   3. The result needs to indicate whether an intervening restart
>      occurred.
> 
> This fully exposes the restart mechanism to anybody who can perform a
> sleep operation, but I simply do not see any way to rationalize sleep
> without this. A checkpointing system is capable of a restricted form of
> "time travel", so a notion of time travel epoch would appear to be
> intrinsic.

That seems like a reasonable set of semantics for the kernel's sleep.
I'm not sure what you'd do for the "real time" alarm service.


  Sam

 [1] http://www.coyotos.org/pipermail/coyotos-dev/2007-January/000728.html