I've reworked the previous BlockingQueue example to use a thread pool. Suppose you wanted to decompose your input into a large number of different types, you would end up with an excessive number of threads if you tried to have one thread for each type. The example code below uses the poll method of BlockingQueue with a timer. When the poll expires, the thread wrapping the worker is interrupted and is returned to the thread pool to be reused.

• threadrunner-pool-20100224.jar (2010-02-24 @ 05:34:45 PST)

"A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World" is brilliant. Every programmer needs to read this.

The analysis of the human factors involved in software development is spot on.

I was inspired by some code I looked at to play around in Java with BlockingQueues.

I wrote a trivial application which uses the following algorithm:

• generate events and put them in an event queue
• simultaneously, read events from the queue and decompose them into flavors, assign each flavor to a new work queue
• simultaneously, drain work queues in parallel

When running the application you can experiment with different values for the number of events, the maximum size of the BlockingQueues used by the event queue and the workers.

Binary and source code:

threadrunner-20100210.jar (2010-02-10 @ 20:33:27 PST)

I've created an incredibly boring video to go with this. It reminds me of an ancient algorithmic MIDI note generator I once loved.