lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: help on Lock.obtain(lockWaitTimeout)
Date Fri, 22 Sep 2006 11:01:22 GMT
Doron Cohen wrote:
> For obtain(timeout), to prevent waiting too long you could compute the
> maximum number of times that obtain() can be executed (assuming, as in
> current code, that obtain() executes in no time). Then break if either it
> was executed sufficiently many times or if time is up. I don't see how to
> prevent waiting too short.

Yeah this is still relying on the system time to measure elapsed time
which is [sadly, sneakily] dangerous.  I'm afraid it will eventually
come back and haunt us (me!) if we do this.

Actually, there is a java.util.Timer, but 1) it goes an launches
another Thread under the hood, and 2) apparently (some posts I found
through Google), there are clock-shift cases where even this class is
in fact unreliable.

> Btw, I wonder what happens if the time change as of sync occurs in the
> middle of the sleep - since sleep is implemented natively this must be
> taken care of correctly by the underlying OS...?

I *think* sleep is in general robust to clock shifting.  At least, I
sure hope so, because using sleep to make a separate [low resoution]
clock thread has been my workaround for this issue (not relying on
system time to measure elapsed time) in the past.  I believe (I hope!)
I had tested this in the past and came to this conclusion.

There is the spooky InterruptedException that Thread.sleep can throw
-- I think it's only if another thread explicitly interrupts this
thread but I'm not certain?  The sleep() call (in C on many Unix's)
will also stop early if a signal is received while it's sleeping.

Time is just never simple!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message