[coyotos-dev] Sleep, wakeup, and persistence

Jonathan S. Shapiro shap at eros-os.com
Fri Sep 14 14:03:51 EDT 2007


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.

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.

  2. If the system crashes but revives before the timeout, there is
     a question what to do.

In the first case, the problem is that it is not possible to express an
absolute time within the kernel. If the system is non-persistent, this
is not really a problem, since everything will be re-starting from
ground zero across the entire system. If the system is persistent,
however, there is a serious problem. An application may learn the wall
time from an external reference source (e.g. an NTP daemon), and may
then say "I wish to sleep until 5pm". This will get turned into a
power-on relative time. If the application gets checkpointed while
sleeping, it will immediately re-issue this request on restart, and it
may end up sleeping much later than it intends.

The second case is a problem because the wakeup time may be much later
than desired (we may be down at the requested wakeup time).

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.
-- 
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org



More information about the coyotos-dev mailing list