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

[Peter Jones]

On Wed, Feb 14, 2007 at 05:46:15PM +0100, Oliver Pfeiffer wrote:

> 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? :)

You're reusing the same thread pool for each repeat of the test,
right?  (It appears to be statically initialized once for the test
class.)  I suspect that occasionally one (or more) of the pooled tasks
from a previous test run have not fully completed as far as the thread
pool is concerned, so during the next test run, the main loop gets
blocked on a iteration earlier than the 17th, and then a barrier await
times out because the main loop cannot submit the 17th task, which
breaks the barrier.

-- Peter