<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2012-07-12 23:55, Erik Søe Sørensen
wrote:<br>
</div>
<blockquote
cite="mid:CAO1s=UWo+BW_RSR-LJRnZB2SULXSo0Ee5y=XkskxCrZEf5zLgQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">2012/7/12 Wojtek Narczyński <span
dir="ltr"><<a moz-do-not-send="true"
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.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(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>
</blockquote>
<br>
I looked into the Erjang repo, and indeed now_unique_micros() looks
good, so I honorably retreat.<br>
<br>
<blockquote type="cite">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.</blockquote>
<br>
I suspect that there are some serious differences between platforms,
because on Unix the POSIX API (clock_gettime and friends) is a clean
one - you have a choice of different clocks with different
characteristics. Erlang exposes only one clock, the most expensive
one possible - strictly increasing [0, 1, 2, 3, ...], basically a
clock and a counter in one. Using atomic operations instead of locks
would definitely be faster. But still slower compared with an
increasing clock [0, 1, 1, 2, ...], and other clocks. Certainly, it
would be nice to have that POSIX choices in erlang. I have been
surprised once by erlang:now() performance on multiclore, but still
I do not think this is big issue.<br>
<br>
--Regards,<br>
Wojtek<br>
</body>
</html>