CODEWITHSUNDEEP
c++design-patterns
Rajendra Uppal
Rajendra Uppal

Reputation: 19914

Object pool design pattern problem

For object pools, we say that whenever client asks for a resource, we give it from the pool. If I checked out one resource and changed its state and checked it in. What happens on the next request, does the pool let client check out this resource or this resource is invalid for the pool now?

Upvotes: 1

Views: 1310

Answers (2)

Blah0x7B9
Blah0x7B9

Reputation: 220

Or, alternatively, you should not return the resource back to the pool until the resource is back to its original state. For example, imagine you have a web server with a listener thread and a pool of 10 worker threads. The listener thread accepts incoming http requests and dispatches them to the worker threads for processing. Worker threads in the pool (not checked-out) are in their "original" state, i.e. idle, or not processing a request. Once the listener thread checks out a worker thread and gives it an http request, the worker thread begins processing the request; in other words, its state is "working". Once it's done processing the request and has sent the http reply to the client, it is "idle" again and goes back into the pool. Thereby, all threads not currently checked out of the pool are always in their original state, "idle".

Upvotes: 0

Martin James
Martin James

Reputation: 24857

If the object released to the pool became invalid for re-use, the pool would be somewhat pointless. If a class requires initialization, or re-initialization, you could do it in the get() or release() pool methods. If reinitialization requires much more than simple assignments, (eg. a pool of socket objects that must not be re-used for 5 minutes), then you may have to resort to a dedicated pool manager thread that effectively splits the pool into a couple of puddles - those objects available for re-use and those awaiting reinitialization.

Rgds, Martin

Upvotes: 1

Related Questions