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...? [EMAIL PROTECTED] wrote on 21/09/2006 13:05:06: > On 9/21/06, Michael McCandless <[EMAIL PROTECTED]> 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 > http://incubator.apache.org/solr Solr, the open-source Lucene search server > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
