My preference for this functionality on machines that do not have an user-mode timer (almost everything but the 370 and descendants) is to have the kernel maintain a timer in a page which is accessible R/O from user land (Charles' last option).
370 KeyKOS had code, for example the transaction processing system, that depended on some additional features of the 370 TOD clock. One of these was that the clock would never give the same answer when read. This feature allowed it to be used for generating serial numbers. Another was that reading the clock was a "block concurrent" operation which updated memory atomically as seen by all processors. I despair of building these functions in software with 1-2 memory cycle efficiency.
At 3:44 PM -0700 11/9/98, Landau, Charles wrote:
>If the time-of-day page is implemented in hardware, it's obviously not very
>portable.
>
>If it's implemented by trapping references to the page, it's no faster than
>a kernel call.
>
>If it's implemented by updating a page whenever the time changes (the
>resolution being low enough to make this feasible), there is no need to do
>this in the kernel. Any user can provide this service by waiting until a
>time change and updating an ordinary page.
>
>
>-----Original Message-----
>From: Jonathan S. Shapiro [mailto:jsshapiro@earthlink.net]
>Sent: Monday, April 27, 1998 3:39 PM
>To: eros-arch@eros.cis.upenn.edu
>Subject: time of day (EROS/KeyKOS divergence)
>
>
>Fetching the current time (either since startup or since some epoch)
>is a high-frequency operation in some codes. Some machines lack a
>hardware instruction to provide this. On the x86, it's really worth
>avoiding a kernel call to find out the answer. [The particular context
>is networking code, where the minimal interpacket delay is of the same
>order as the kernel call delay]
>
>I'm therefore leaning toward a "time of day" page, which is a
>kernel-implemented page that exposes both values to the caller via a
>shared-memory interface.
>
>Access to this page may want to be closely held, but does anyone see
>an objection in principle?
>
>
>shap
Bill Frantz | Macintosh: Didn't do every-| Periwinkle -- Consulting (408)356-8506 | thing right, but did know | 16345 Englewood Ave. frantz@netcom.com | the century would end. | Los Gatos, CA 95032, USA