erlang:now() in erlang 4.9.1 on Linux

[Thomas Arts]

Ulf Wiger wrote:


> This is a tricky issue, and it's certainly compounded by the fact
> that erlang:now() *is* used both for unique IDs and for time
> representation. There are basically two reasons for this:
> 
...

> I would like to see a new function, e.g. hrtime(), in Erlang, and
> a shift in focus of erlang:now() to become a (strictly increasing)
> internal real-time clock. It is vital that Erlang has a sense of
> time that keeps ticking in one distinct direction, regardless of
> what the system clock says.

The problem cannot be solved by introducing a new function. The fact that
now() presents the time in microseconds automatically implies that calls
within microseconds will return the same value. If hardware gets faster,
the risk of returning the same value increases.
Sure, one can introduce pico-seconds, postponing the discussion for 9.5 years,
but that on itself does not solve the problem. One needs to be able to
guarantee increments.

My first intuition is that one needs to guarantee the function now() to have an
execution time at least the smallest time that it can measure. Thus, if one
executes now() on a very fast machine, it should at least take a microsecond.
If the machine is too fast for that, let now() wait! Compile the runtime system 
on a target machine and put a special constant in for now() to wait. This seems
like a terrible waist of cpu time, but it is only necessary on machines that are
faster than now()'s accuracy. If one is waiting too much, one increases the 
precision.

Another thing one could try is to add a clocktick system. Whenever the runtime
system is executing a "symbolic" instruction, the clocktick is increased. I guess
one needs 8 bytes or such to have a reasonable representation, need not be more
than the expected livetime of hardware ;0). The bytes are read when ticks() is
evaluated and that gives a guaranteed increment. However, every instruction
(or a special kind, e.g. every read from the heap) is slower since it should add
1 to the 8 bytes in memory.

/Thomas