2012/7/12 Wojtek Narczyński <>
> On 07/12/2012 08:23 PM, Erik Søe Sørensen wrote:
>>> Because of atomic operations.
>> I may not have been explicit enough there: latest_now is a
>> java.util.concurrent.**AtomicLong, and the two updating accesses to it
>> are atomic.
>> long prev;
>> while ((prev = latest_now.get()) < micros) {
>> if (latest_now.compareAndSet(**prev,micros)) {
>> return micros;
>> }
>> }
>> return latest_now.incrementAndGet();
>>>> This - and only because of this - means that no lock is necessary.
>>> Oh, I think I understand now.
>> You want to have one coarse-grained clock - protected by a lock, and
> another one fine-grained - updated atomically.
>> Do I understand correctly now?
>
Indeed :-)
Roughly speaking, Erlang calculates now() from a monotonic, hi-res time
source plus a lower-res absolute-time source.
The now-time is the monotonic time plus a certain offset, which may change
over time in a controlled fashion, and which is adjusted only when the
monotonic source has made a certain amount of progress.
This is more or less what already happens, at
https://github.com/erlang/otp/blob/master/erts/emulator/beam/erl_time_sup.c
line 172. The variant at line 262 and forth is somewhat more complex to
follow; I'm afraid it doesn't follow the pattern as things are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120712/b3632c13/attachment.html>