[concurrency-interest] How has java.util.concurrent.locks been tested?

Oliver Zeigermann ozeigermann@apache.org
Thu, 30 Dec 2004 14:01:04 +0100

On Wed, 29 Dec 2004 19:19:43 -0500, Doug Lea <dl@cs.oswego.edu> wrote:
> > E.g. in testhasQueuedThreads I have found
> >
> > Thread.sleep(SHORT_DELAY_MS);
> >
> > which - I suppose - does what I was trying to do with my sequence
> > barrier.
> Since ReentrantLockTest etc are tests of basic blocking/locking
> facilities, we can't use locks themselves to block threads, so must
> use the rule that implementations pass if there exists some value for
> SHORT_DELAY_MS that succeeds. It is not a bad convention in some other
> kinds of tests as well, since it avoids needing intricate synch to set
> up tests.

Certainly not ReentrantLock's, but why not using others based on
ordinardy synchronized/wait/nodify stuff?

> > Especially when  you debug your code this is likely to fail,
> > isn't it?
> Yes, but these TCK tests aren't especially good for debugging anyway.

Did not want to criticize the TCK tests in any way. I am just trying
to find out what would be the best way to test concurrent stuff apart
from the stress tests you mentioned.

Any chance to see the code of your other tests?