4

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?

Improve this question
0

2 Answers 2

Reset to default
5

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.

Improve this answer
0
0

I think you are talking about FlyWeight pattern: http://en.wikipedia.org/wiki/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.

Improve this answer
6
  • Right, pattern matches in sense of persisting processor objects. And thanks for operations hint.
    – mikalai
    Commented Nov 23, 2011 at 11:13
  • 2
    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
    Commented Nov 23, 2011 at 11:27
  • @PéterTörök - why not? With slight modification of course.. Wouldn't you propose some other way?
    – mikalai
    Commented Nov 23, 2011 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
    Commented Nov 23, 2011 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
    Commented Nov 23, 2011 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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