Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my application requests are processed by objects of Processor-derived classes, something like CreateItemProcessor or MoveItemToGroupProcessor. Base Processor class implements most of common processing logic, and derived ones make some specific business logic related tasks.

An object of a certain processor type is created before request processing, and then wiped out afterward.

Eventually it came to a situation, when creation of a single processor object was taking major part of request processing time. So now I'm thinking about creation of a pool of request processor objects, and reuse them instead of using create/delete approach.

The problem here is that any single Processor object is not thread-safe, and actually shouldn't be tread-safe: it stores request-specific data inside. So my general approach to that is as follows:

  • Try to acquire 'processor' from a pool;
  • If there are no any available, wait;
  • When we have processor available, mark that as 'working' and start processing;
  • When job is done, "return" processor to the pool;
  • Notify pool that free processor is available.

Is there a kind of design pattern for that? Am I missing something from the existing GoF patterns? Any C#-related implementation details?

share|improve this question
up vote 5 down vote accepted

Yes there is, and it is named (rather unsurprisingly) Object Pool :-)

Googling for a C# implementation pops you up a StackOverflow thread in the first place.

share|improve this answer
whoah, how suprinsing! thanks :) – mikalai Nov 23 '11 at 13:33

I think you are talking about FlyWeight pattern: It is used in ThreadPool or database connection pools.

Regarding implementation - You can have a queue(s) of available processors. On request arrive you pop processor and return it back to the queue after completion. In this case your processor can be thread unsafe. There is a need to sync on queue access though.

share|improve this answer
Right, pattern matches in sense of persisting processor objects. And thanks for operations hint. – mikalai Nov 23 '11 at 11:13
No, Flyweight is definitely NOT meant (nor used) to implement object / thread pools. Just read the referred Wikipedia article carefully. – Péter Török Nov 23 '11 at 11:27
@PéterTörök - why not? With slight modification of course.. Wouldn't you propose some other way? – mikalai Nov 23 '11 at 11:33
@mikalai, a FlyweightFactory gives you always the same physical object for the same kind of query (e.g. for the "Euro" glyph in a word processor), but different objects for a different kind of query. Thus all Euro glyphs in the text share the exact same (usually immutable) state. Whereas an Object Pool serves you one random available object, and you don't care which one, because they have no identity, and their state may be important only during processing a request - but you definitely DON'T want them to share their state with each other. – Péter Török Nov 23 '11 at 11:41
@mikalai, the "slight modifications" would turn your Flyweight into a different pattern - see my answer for details. The implementation of these two patterns may look slightly similar, but their intent and purpose is rather different. – Péter Török Nov 23 '11 at 11:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.