lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <>
Subject Re: help on Lock.obtain(lockWaitTimeout)
Date Thu, 21 Sep 2006 20:49:44 GMT
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.

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...? wrote on 21/09/2006 13:05:06:
> On 9/21/06, Michael McCandless <> wrote:
> > Anyway, my first reaction was to change this to use
> > System.currentTimeMillis() to measure elapsed time, but then I
> > remembered is a dangerous approach because whenever the clock on the
> > machine is updated (eg by a time-sync NTP client) it would mess up
> > this function, causing it to either take longer than was asked for (if
> > clock is moved backwards) or, to timeout in [much] less time than was
> > asked for (if clock was moved forwards).
> Um, wow... that's thorough design work!
> In this case, I don't think it's something to worry about though.
> NTP corrections are likely to be very small, not on the scale of
> lock-obtain timeouts.
> If one can't obtain a lock, it's due to something else asynchronously
> happening, and that throws a lot bigger time variation into the
> equation anyway.
> -Yonik
> Solr, the open-source Lucene search
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message