Jump to content

Pool (computer science)

From Wikipedia, the free encyclopedia
(Redirected from Process pool management)

In computer science, a pool is a collection of resources that are kept in memory, ready to use, rather than the memory acquired on use or the memory released afterwards. In this context, resources can refer to system resources such as file handles, which are external to a process, or internal resources such as objects. A pool client requests a resource from the pool and performs desired operations on the returned resource. When the client finishes its use of the resource, it is returned to the pool rather than released and lost.[clarification needed]

The pooling of resources can offer a significant response-time boost in situations that have high cost associated with resource acquiring, high rate of the requests for resources, and a low overall count of simultaneously used resources. Pooling is also useful when the latency is a concern, because a pool offers predictable times required to obtain resources since they have already been acquired. These benefits are mostly true for system resources that require a system call, or remote resources that require a network communication, such as database connections, socket connections, threads, and memory allocation. Pooling is also useful for expensive-to-compute data, notably large graphic objects like fonts or bitmaps, acting essentially as a data cache or a memoization technique.

Special cases of pools are connection pools, thread pools, and memory pools.

Object pools

[edit]

Pools can also be used for objects, in which context a pool refers to a design pattern for implementing pools in object-oriented languages, such as in the object pool pattern. Objects themselves hold no external resources and only occupy memory, although an already created object avoids the memory allocation required on object creation. Object pools are useful when the cost of object creation is high, but in certain situations this simple object pooling may not be efficient and could in fact decrease performance.[1]

References

[edit]
  1. ^ "Java theory and practice: Urban performance legends, revisited". ibm.com. 2005-09-27. Archived from the original on 2011-12-29. Retrieved 2013-10-31.