Pools

Pools are a set of pre-allocated areas of memory or objects. Pool users typically ask the 'pool' for a handle to an unused object or area, and then tell the pool when it's finished with it. Pools are used:

in languages that have no dynamic memory allocation (or in certain critical software where dynamic memory allocation is unacceptable) but where a variable number of objects need to be handled, such as a message queue. So a number of structures are allocated in memory, and this 'buffer' or 'pool' of objects are used and marked 'unused' as necessary.
in languages where allocating and deallocating certain objects is a significant performance hit.

Including Pools

Pools are very similar to heaps, and the possible problems are similar: 'leaking' where pool objects are not released, and overwriting where two pool users end up using the same pool object.

As pools are often shared between threads or processes, they must typically be threadsafe. This also makes thorough testing more difficult as race and deadlock conditions often change from platform to platform, and you must rely on careful design, coding and Code Reviews.

Standard 3rd party libraries exist for the common pooling objects (eg Thread and JdbcConnection in Java). These suffer (and gain from) the standard reuse issues in ReuseOrBespoke.

When to do so?

Pools are often necessary; my comments above just point out some of the pitfalls. However pitfalls exist, so don't do it just to Optimise Code when there is no significant performance hit. It's commonly done in java with creating JdbcConnection and Thread objects which on some platforms used to be slow operations, and commonly causes errors that you won't get with a simple new Thread(); statement.

Martin's Home Site (yawn)

(Created using Dreamweaver, and very nice it is too)

Last modified - - Thursday, 29-May-2008 22:45:07 BST

Hosted by Ghoulnet