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><br><br><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 07:27 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">
Why not? That's certainly the intention of the last part; latest_now should always be updated in a increasing manner, and the return value of ensure_monotonically_<u></u>increasing_now() should always be equal to the new value of latest_now.<br>

Did I make a mistake?<br>
</blockquote>
<br></div>
Well, how do you "ensure" it without taking a lock? Meanwhile the global value can be increased by another thread, to what you calculate locally.<br>
<br>
--Regards,<br>
Wojtek<br>
</blockquote></div><br>