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! Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
