[concurrency-interest] ThreadPoolExecutorTest occasionally fails with a broken barrier!?

Oliver Pfeiffer pfeiffer at tzi.de
Wed Feb 14 11:46:15 EST 2007


> >   public void testThreadPoolExecutor() throws InterruptedException {
> >     final int threads = THREAD_POOL_EXECUTOR.getMaximumPoolSize();
> >     final int loops = threads * 16;
> >     final CountDownLatch latch = new CountDownLatch(loops);
> >     final AtomicInteger counter = new AtomicInteger();
> >     final CyclicBarrier barrier = new CyclicBarrier(threads + 1);
> >     for (int i = 0; i < loops; i++) {
> >       THREAD_POOL_EXECUTOR.submit(new Runnable() {
> >         public void run() {
> >           if (counter.incrementAndGet() <= barrier.getParties()) {
> 
> Presumably your intent is to have each thread hit one barrier.
> But sometimes, one thread will hit two or more, and others will
> hit zero. In those cases some will be waiting for a thread that
> never arrives, timing out on barrier.

No, the pool has a maximum of 16 threads and the test-loop repeats 256 times
(16*16) but the barrier is set to 17 (16+1). Thus only the first 16 pool
threads and the main thread itself (callers run policy) hit the barrier.
After the main thread trips the barrier they should continue all at once to
finish the remaining loops (without further barrier checking due to the
counter check).

The test should perform as follows:

T.01-T.16 arrive barrier and wait
T.main arrives barrier and trips it
barrier trips -> T.01-T.16 and T.main continue
T.01-T.16 only count the latch down without hitting the barrier (counter
check)

Thus the major question is still: Why does it occasionally fail? :)

Oliver



More information about the Concurrency-interest mailing list