<div class="gmail_quote">2012/7/12 Wojtek Narczyński <span dir="ltr"><<a href="mailto:wojtek@power.com.pl" target="_blank">wojtek@power.com.pl</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 07/12/2012 08:23 PM, Erik Søe Sørensen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Because of atomic operations.<br>
I may not have been explicit enough there: latest_now is a java.util.concurrent.<u></u>AtomicLong, and the two updating accesses to it are atomic.<br>
                long prev;<br>
                while ((prev = latest_now.get()) < micros) {<br>
                        if (latest_now.compareAndSet(<u></u>prev,micros)) {<br>
                                return micros;<br>
                        }<br>
                }<br>
                return latest_now.incrementAndGet();<br>
<br>
This - and only because of this - means that no lock is necessary.<br>
</blockquote></div>
Oh, I think I understand now.<br>
<br>
You want to have one coarse-grained clock - protected by a lock, and another one fine-grained - updated atomically.<br>
<br>
Do I understand correctly now?<br></blockquote><br></div>Indeed :-)<br>Roughly speaking, Erlang calculates now() from a monotonic, hi-res time source plus a lower-res absolute-time source.<br>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.<br>
This is more or less what already happens, at<br>  <a href="https://github.com/erlang/otp/blob/master/erts/emulator/beam/erl_time_sup.c">https://github.com/erlang/otp/blob/master/erts/emulator/beam/erl_time_sup.c</a><br>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.<br>