design-patterns - 並行プログラミングのパターンですか？

Question

いくつかの OOP デザインが頭に浮かびました。プールと工場のようなものです。

ファクトリは、複数のスレッド間で共有できるリソースを作成します。1 つのリソースエンティティは高価であり、その作成には多くの時間がかかります。リソースは、一度に複数のスレッドで使用できます。

私の特定のケースでは、リソースは SSH 接続です。SSH 接続は 1 つの TCP ソケットを使用します。ただし、1 つの SSH 接続に複数のセッションを含めることができます。各スレッドは、それ自体の新しいセッションを作成します。セッションの作成では、ファクトリを操作する必要はありません。

複数のスレッドが同じリモートホストと対話しようとする場合があります。

リソースのステータスを定義しました。

init 一部のスレッドが SSH 接続を取得しようとしましたが、存在しません。リソースの作成には長いプロセスがあります。別のスレッドも同じリソースを取得しようとすると、必要なリソースが進行中であることがわかり、2 番目のスレッドは通知を待ちます。

free すべてのセッションが閉じられ、SSH 接続を使用するスレッドはありません

ビジー少なくとも 1 つのスレッドが SSH 接続を取得しました

閉じられた TCP ソケットが破棄されます

リソースの状態図があります。

OOP パターン、エンタープライズアプリケーションパターン、並行パターンに関する本を読んでいますが、上記の状況を思い出せません。

SSH は単なる例です。このパターンは、同時作業をサポートする重いリソースに適しています。2 番目のスレッドが作成中のリソースを取得したいが、リソースの 2 番目のインスタンスを作成するのはナンセンスです。

それがパターンなら、彼の名前は何ですか？このデザインはすでにどこかに記載されていると確信しています。

score 0 · Accepted Answer

私が得たように、「接続プール」の問題を解決する必要があります。接続プールは「プーリングパターン」の実装です。

パターン（私が見ているもの）との違いは、実装では、セッションのユーザーが接続とプーリングのものとのマングリングについて何かを知っているということです。

私にとっては、ユーザーがセッションプールからセッションを注文し、それを返す場合、より「パターンの方法」のようです。そのため、プーリングシステムは必要な接続があるかどうかを認識し、作成/破棄メカニズムはユーザーに対して透過的です。ユーザーはセッションを持っているため、「接続」を取得します。

セッションの作成では、ファクトリを操作する必要はありません。

それは本当かもしれませんが、セッションのライフサイクルは接続のライフサイクルにとって不可欠です。したがって、オブジェクトを使用するのではなく、プールを作成/破棄する責任を負います。

1 に答える 1