However, I was thinking of re-writign the test with a custom tast that would use a custom task to incrament/decrament a static counter, and I would just asser that the max value was less than or equal to the thread count. That's really the behavior the test needs to assert, and we can reduce the amount of time it takes to run the tegt with that setup. This is consistent with the behavior that start order can be guaranteed, but execution and finish order are up in the air, classic race condition stuff.
--Danno
Conor MacNeill wrote:
Danno Ferrin wrote:
That looks like code I submitted, could you tell me OS and JDK versions you are running for this failure? I may need to re-do the unit test to be tolerant of nideterminate behavior :(
I have added some delays to ensure tasks start in the order specified. When you start three threads, the third may end up running before the second. the old code would fail sometimes for me (Linux RH8.0, JDK 1.4.1_01)
BTW, any doco update?
Conor
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
