0

この状況の既知の解決策 (生産者と消費者の問題として) を探しています。

私の場合、2 つのオプションがあります。

  • 画像へのリンク,
  • 画像へのリンクと他のテキスト ファイルへのリンク (他のリンクを含む) を含むテキスト ファイル。

posix mutexとposix semaphoreを使用して、 C++ (unix 上)でマルチスレッド ダウンローダーを作成しようとしています。

アプリケーションには、最初のテキスト ファイルへのリンクがあります。

  1. スレッドはスリープします (セマフォ = 0)。
  2. メイン スレッドが最初のテキスト ファイルをダウンロードします。
  3. 他のリンクを解析します -- リンクをいくつかのキューに入れます (セマフォ += links_count --> 他のスレッドが起動します)。
  4. 他のスレッドは他のリンクを生成します。

メインスレッドは？他のスレッドを確認する方法 -- 終了状態?

有限キューを使用すると、デッドロックが発生する可能性があります。テキスト ファイルには多くのリンクが含まれています (キューは他のテキスト ファイルでいっぱいになります)。テキスト ファイルを完成させることはできません。

アイデアありがとうございます。

4

1 に答える 1

1

さて、あなたの問題はまだ生産者/消費者の問題ですが、消費者も生産者です。問題に対処するいくつかの方法:

  • キューのサイズを制限しないでください。プロセスがメモリ不足になると、単純に失敗します。あまりエレガントではありませんが、おそらくすべてのダウンロード シナリオの 99.99% で動作します (ダウンロード リンクごとに平均 100 バイトと約 2GB の使用可能なメモリを想定すると、メモリが不足する前にキューに 2000 万を超えるリンクを格納する必要があります)。
  • ハードドライブをバッファーとして使用して、プロデューサーとコンシューマーを分割します。ファイルを一時フォルダーにダウンロードします。そのフォルダーに新しいファイルがないかスレッドで監視します。新しいファイルが表示されたら、それを解析し、アイテムをコンシューマー キューに入れます。ファイルの解析が終了したら、最終的なダウンロード場所に置きます。この方法では、ディスク容量によってのみ制限されます。このようにして、プロデューサー (パーサー) はコンシューマー (ダウンローダー) とは異なるスレッドになります。

編集

pthread_joinメインスレッドでワーカースレッドを待つことができます。

于 2012-06-02T19:37:24.707 に答える