Logic of Thread Pools

I'm struggling a bit to fully understand the implementation of thread pools. I grasp the meta-level concepts behind the thread pool (thread creation is expensive, so create a batch of them in advance and have them pick up tasks out of an incoming queue). I get a little lost in the implementation details, however. I reviewed a code example which had a "Done" object, and I don't quite get it.

Could somebody walk me through the flow of a thread pool and explain the necessary parts to implement?

Thanks in advance.

Maybe looking at Doug Lea PooledExecutor will help you. He documents it very well.

./pope

I also found the Apache Commons Threadpool an interesting read. The core to both of these (to me anyhow) was a blocking queue. Clients put commands to be executed (runnables) into a queue. Some number of threads pick commmands out of the queue in FIFO order and execute them. The blocking bit is important when the queue is empty ... threads block until something appears in the queue and then proceed. It can also be important when the queue is full ... clients may block until there is room to insert the item. The blocking queues in Java 5.0 are wonderfully tunable for how big to grow, what to do when full and so on.

thread creation is expensive, so create a batch of them in advance and have them pick up tasks out of an incoming queue

It is actually a bit more complex than that, it is a matter of throughput. On average, it may be quicker to service clients by servicing a limited number of them, in order, than to service them all simultaneously. A good case for a threadpool, is to actually limit the number of available threads.

Henry