On Thu, Nov 29, 2001 at 09:59:10AM -0800, Ryan Bloom wrote: > On Thursday 29 November 2001 09:45 am, Brian Pane wrote: > > Right--the fact that the transaction pools are children of a pool > > owned by the listener thread means that we have to do locking when > > we destroy a transaction pool (to avoid race conditions when unregistering > > it from its parent). > > I'm not sure this will fix the problem, but can't we fix this with one more level > of indirection? > > Basically, the listener thread would have a pool of pools, one per thread. > Instead of creating the transaction pool off of the man listener pool, it creates > the pool of pools off the listener pool, and the transaction pool off the next > pool in the pool of pools. > > listener > > sub-pool1 sub-pool2 sub-pool3 > > trans-pool trans-pool trans-pool > > The sub-pools are long-lived, as long as the listener pool. By moving the > trans-pool to under the sub-pool, and only allowing one trans-pool off > each sub-pool at a time, we remove the race-condition, and can remove > the lock.
That also opens us up for the possibility of pool reuse as well as cache hit performance. We implement the "pool of pools" as a simple mutex-protected stack with a set number of pools equal to the number of threads (or maybe one extra). Then we make sure that the worker clears and returns the pool before reentering the worker queue. We don't get the benefit of reusing the most recent thread, which would give us cache hits on that thread's stack segment, but we do get hits on the pools, and we even reduce overall memory consumption since the pools that grow to meet the demand are reused (and we don't force all pools to grow to meet the peak demand). Interesting. -aaron
