I analysed this problem.It appears that the pthread_cond_timedwait on at least darwin8 sometimes returns a few microseconds early; this may be related to having ntpd running.
On darwin9 (and/or darwin8 with -D_APPLE_C_SOURCE defined), sometimes this test hangs, due to a different, known, bug in pthread_cond_timedwait.
I would suggest just xfailing this test on Darwin, except I don't see how to do that in this directory. Alternatively, the problem can be suppressed by testing for 49 instead of 50.
According to the Java language specification, it is not actually incorrect for this test to fail. In section 17.9, it says "Thread.sleep causes the currently executing thread to sleep (temporarily cease execution) for the specified duration, subject to the precision and accuracy of system timers and schedulers." The implication is that Thread.sleep might use a different system timer than currentTimeMillis (one which runs at a different rate), which I think is what's actually happening at least in the darwin8 case.
smime.p7s
Description: S/MIME cryptographic signature
