(Maciek へのコメントにも基づいて) スレッドとプロセスの違いと、それらがどのように通信できるかを理解することから始めなければならないと思います。
デザインの問題について: シンプルなデザインから始めてみてください。たとえば、スレッドのみを使用し、各サブスクライバーに、独自の同期キューを使用してジョブに shared_ptr を渡します*。データへのアクセスは読み取り専用であり、AFAICR では、boost::shared_ptr はそのような使用に対して安全なマルチスレッドであるため、同期の問題はなく、データは自動的に消去されます。(まだ)メモリの再割り当てについて心配する必要はありません。サブスクライバ/スレッドごとに有限量のメモリ(o(1))(あなたが言ったように、最大で約51個のshared_ptrs)を使用していることを確認してください。
この動作するスケルトンができたら、遭遇した問題に基づいて最適化を開始できます。再割り当てが問題の場合は、リング バッファーに移動できます (bcat で提案されているように)。または、アロケータ (/new 演算子) をプール アロケータに置き換えることができます。サブスクライバが多数ある場合は、すべてのスレッドで使用される単一のキューにキューをマージすると効果的です。これを行うには、より多くの情報が必要です (非常に長い計算のために 1 つのスレッドが非常に遅い場合はどうなりますか? 処理を停止するようにスレッドに通知する方法はありますか? または、キューが大きくなる必要がありますか? この場合、循環バッファーは機能しない可能性がありますまあまあ...) 複雑になるかもしれませんが、(ジョブではなく) shared_ptrs によって占められている部屋を保存しようとしているだけであることを忘れないでください。
要するに、時期尚早の最適化を避けるようにしてください。代わりに、合理的な最適化と拡張性を備えた設計を作成し、学んだことに基づいてそこから先に進みます。
幸運を
* 同期キュー - スレッド間のキュー。push(j) はジョブを追加し、pop() はキューが空でなくなるまで待機し、一番上のジョブを返します(stl::queue とは異なります。キューが複数のスレッドによって読み取られる場合、これは重要です)。通常、stl::queue をラップし、boost::mutex を使用して保護することで実装します。