On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:

Elena Semukhina wrote:
> As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
> yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
> issue
> for that. I saw this failure quite long ago but cannot reproduce it
today
> trying different platforms/EMs. When the test failed, it reported that
> actual wait time is less than required.
>
> The spec for join() reads: "Waits at most millis milliseconds plus
> nanosnanoseconds for this thread to die. " There is an obvious
> misprint here:
> there should be "at least" but not "at most" and this was mentioned in
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368
>
> On the other hand, in classlib ThreadTest I saw that they agree with
> Thread.sleep(1000)  duration >= 800 and join(100, 999999) duration <=
300.
>
> Can the current DRLVM guarantee that it does not exit join() earlier
than
> expected?
> If not, we should make the test more tolerable to timing.

There is also an unstable ObjectTest.testWaitlongint which fails once in
a while (about once in 50 - 100 runs). It also seems to wait a bit less
than required. I think there is also a bug in the test, nanos should be
500000, not 500. But fixing this doesn't help, test still fails on
windows.


Gregory, why do you think this is a bug? nanos can be any value between 0
and 999999. Actually there is a bug in thread_native_condvar.c which ignores
any nanos < 1000 when converting them to microseconds.

The spec for Object.wait(long) reads that waiting lasts until:
...
The specified amount of real time has elapsed, more or less.

It does not say neither "at most" nor "at least". I think we can fix both
tests so that they could wait a little bit less than it is now expected and
print the values at error messages. I attached a patch to HARMONY-2204.
Please take a look and commit if it is OK. Then we can see if the tests
still fail.

I checked the APR function and underlying win API functions, the
System.currentTimeMillis is measured with microseconds accuracy. The
Thread.join and Thread.wait end up with WaitForSingleObject function
which accepts an argument in milliseconds. So I cannot understand why
the wait/join time is less than required.

--
Gregory




--
Thanks,
Elena

Reply via email to