[concurrency-interest] ThreadPoolExecutorTest occasionally fails with a broken barrier!?
peter.jones at sun.com
Wed Feb 14 13:44:02 EST 2007
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
> 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.
More information about the Concurrency-interest