Question

I have a long-running application that basically:

1. read packets off network
2. save it somewhere
3. process it and output to disk

A very common use-case indeed – except both the data size and data rate can be quite large. To avoid overflow of the memory and improve efficiency, I am thinking of a dual buffer design, where buffer A and B alternate: while A is holding networking packet, B is processed for output. Once buffer A reaches a soft bound, A is due for output processing, and B will be used for holding network packets.

I am not particularly experienced on concurrency/multi-thread program paradigm. I have read some past discussion on circular buffer that handle multiple-producer and multiple consumer case. I am not sure if that is the best solution and It seems the dual buffer design is simpler.

My question is: is there a design pattern I can follow to tackle the problem? or better design for that matter? If possible, please use pseudo code to help to illustrate the solution. Thanks.

Answer 1

I suggest that you should, instead of assuming “two” (or any fixed number of …) buffers, simply use a queue, and therefore a “producer/consumer” relationship.

The process that is receiving packets simply adds them to a buffer of some certain size, and, either when the buffer is sufficiently full or a specified (short…) time interval has elapsed, places the (non-empty) buffer onto a queue for processing by the other. It then allocates a new buffer for its own use.

The receiving (“other…”) process is woken up any time there might be a new buffer in the queue for it to process. It removes the buffer, processes it, then checks the queue again. It goes to sleep only when it finds that the queue is empty. (Use care to be sure that the process cannot decide to go to sleep at the precise instant that the other process decides to signal it… there must be no “race condition” here.)

Consider simply allocating storage “per-message” (whatever a “message” may mean to you), and putting that “message” onto the queue, so that there is no unnecessary delay in processing caused by “waiting for a buffer to fill up.”