[coyotos-dev] Sleep, wakeup, and persistence

[Charles Landau]

At 3:22 PM -0400 9/14/07, Jonathan S. Shapiro wrote:
>On Fri, 2007-09-14 at 11:46 -0700, Charles Landau wrote:
>>  At 2:37 PM -0400 9/14/07, Jonathan S. Shapiro wrote:
>>  >On Fri, 2007-09-14 at 11:19 -0700, Charles Landau wrote:
>>  >>  At 2:03 PM -0400 9/14/07, Jonathan S. Shapiro wrote:
>>  >>  >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?
>>  >>  >
>>  >>  >   1. The underlying system may not have a monotonically increasing
>>  >>  >      clock. Many embedded systems do not.
>>  >>
>>  >>  You can store the time base in the checkpoint, and restore it on
>>  >>  restart. Problem solved.
>>  >
>>  >That gets you a monotonically increasing clock. It does not get you an
>>  >accurate interval, which is also required.
>>
>>  If you mean an accurate real-time interval, a real-time clock will
>>  give you that, nothing else will.
>
>Charlie: we are going in circles. The question at hand is: what does a
>real-time clock *mean* in the presence of a restart?

A real-time clock is a device that gives you the current value of 
Universal Time (http://en.wikipedia.org/wiki/Universal_Time) (or the 
equivalent in some time zone).

At 2:03 PM -0400 9/14/07, Jonathan S. Shapiro wrote:
>the problem is that it is not possible to express an
>absolute time within the kernel. ...
>An application ...
>may say "I wish to sleep until 5pm". This will get turned into a
>power-on relative time.

You are approaching this issue with a predetermined implementation in 
mind. I am looking first at the requirements, and suggesting the 
implentation follow.

>  > >  > Perhaps it makes more sense to support different types of sleep:
>>  >>  sleep until a given real time (and time zone)
>>  >>  sleep for x seconds from now
>>  >>  sleep for a given amount of system-up time
>>  >
>>  >All of these can be expressed at user level.
>>
>>  Only if you expose restarts, which would be unfortunate.
>
>You can either have a notion of time or you can avoid exposing
>checkpoints. If there is an internally consistent third option, I would
>welcome a description.

Several such notions of time are needed.

1. One notion of time is absolute real-time. I can say "sleep until 
8:56 on 9/16/2007 UT". This might be used by cron. The system wakes 
you up as soon as possible at or after that time. There is no need to 
expose checkpoint/restart.

2. Another notion is relative real-time. I can say "sleep for 10 
seconds of wall-clock time". This might be useful for timeouts of 
real-time events. This can just get turned into absolute real-time, 
unless you are worried about resetting the clock, or about leap 
seconds. If you are worried about those, then this needs to be a 
separate notion.

3. Another notion is system-up time. I can say "sleep until the 
system has run for at least 5 seconds". This might be useful for 
timeouts of other programs.

Here's how this would work. When I make this call, the current value 
of the system's monotonic clock is recorded somewhere (could be in 
user space). Suppose 2 seconds later a checkpoint is taken. Three 
seconds after that I am awakened. Suppose five seconds after that the 
system restarts. The fact that I was awakened is never saved, so we 
can ignore that. On restart, the system restores its monotonic clock. 
Three seconds after the restart, I am awakened. I am unaware of the 
restart (unless of course I look at the real-time clock; that is the 
case whether or not I sleep).

You can't implement all of these with just a single underlying notion 
of time, unless you expose restarts.

One option is to implement these forms of sleep outside the kernel, 
in a server that is aware of restarts, but does not expose that 
awareness to its clients.