Pipe and Filter, clarification needed

Question

Few questions on Pipe and Filter.

In this example, as illustrated on the image above, when implemented:

1. Should each Pipe be running in a separate thread?
2. Should each Filter be running in a separate thread?
3. Is it fair to say that Pump only "knows" of the first Pipe it sees and knows nothing to the rest of the world? Additionally, is it fair to say that each component "knows" only about components one before and one after?

In other words, a Filter will check to see if there is data ready for it to pick up and process and then and only then 1. handle it and 2. pass it to the next pipe?

Answer 1

Pipe and filter is an application of divide-et-impera which, using modularity, aims at easiness of implementation, and versatility through configuration of the modules involved.

It finds the most usefulness when solving a problem which involves several processing runs of a source stream or object or signal, and request production of a modified stream or object or signal of the same type.

It is based on simple small processing units called filters, all of them following the same contract (they get the same object/stream type and optional parameters in input, and return the processed stream/object). Each filter input can be connected to a (another or also another instance of itself) filter output, or to the source (called pump), similarly each filter output can be connected to a filter input or to the architecture return object/steam (called sink). The connection units are called pipes and are used by a manager class to route the stream/object/signal through different steps of processing done in the filters.

The deal in specifying a contract is that each filter can act autonomously without knowing nothing else about other filters, or about the whole flow processing. That means filters can also been interchanged transparently, generating different final results.

While filter instances could run simultaneously on different streams, pipe and filter pattern is not generally used for concurrent operation, because each filter would mostly require access to the same resource.

• software example: filters in image processing
• real world example: pedal effects processing sound signal between guitar and amp.