2010-11-24 12 views
1

私はスレッドプールを実装しています。各スレッドで必要とされる作業は1〜10秒のCPUなので、従来のスレッドプールを使用するのはうれしいですし、作業単位ごとに新しいスレッドを作成しても構いません。それは問題ではありません。複数のスレッドのうちの1つが終了するのを待ちますか?

N個のワーカースレッドのうちの1つが作業を終了し、より多くの時間(または別の時間を開始する準備ができている状態)がいつマスター制御スレッドに通知されるかを確認したいと思います。私はpthread_joinとpthread_cond_waitを見てきました。 Nの1つを待つ方法はないようです。だから私はマスタースレッドに変数を持たせて、スリープ状態にして作業者に目覚めさせることを考えました。これは、労働者が死ななければ働くようです。しかし、彼らが死ぬと、作業者がコントローラを起こしてから、死ぬまでの間に、私が対処したくないウィンドウがあります。

私はインテルのTBBを見ましたが、必要以上に複雑に見えます。

Microsoft WindowsのPTHREADSからWaitForMultipleObjectsに相当するものはありますか?

+1

私はこれをCとタグ付けしました。そうでない場合は、自由に変更してください。 –

+1

pthread_joinのループ(N)を試してみましたか? http://opengroup.org/onlinepubs/007908799/xsh/pthread_join.html –

+0

私はsmall_ticketに同意します。 n pthread_joinsのループ処理ができないのはなぜですか? – Jay

答えて

3

これは、条件変数の合理的に簡単な使用例です。

mutexで保護されているアクティブな作業項目の数を整数で表します。さらに、2つの条件変数を持ちます.1つは作業中のワーカースレッドに信号を送るためのもので、もう1つはスレッドが終了したメインスレッドに信号を送るためのものです。次のようなものがあります。

main: 
    set freethreads to numthreads 
    init mutex M, condvars TOMAIN and TOWORKER 
    start N worker threads 
    while true: 
     wait for work item 
     claim M 
     while freethreads == 0: 
      cond-wait TOMAIN, M 
     put work item in queue 
     decrement freethreads 
     cond-signal TOWORKER 
     release M 

worker: 
    init 
    while true: 
     claim M 
     while no work in queue: 
      cond-wait TOWORKER, M 
     get work to local storage 
     release M 
     do work 
     claim M 
     increment freethreads 
     cond-signal TOMAIN 
     release M 

ループは永遠に実行されます。実際には、それらを終了させ、終了/クリーンアップコードを実行するような信号があります。

+0

'COND-signal'は、ミューテックスを解放する*前*行わなければならない - そうでない場合、スレッドは、条件をテストし、待っている間に知らされるかもしれません。 – caf

+0

ええ、@caf、私はあなたがあなたのコメントを書いていたときにそれを認識しました。更新するように更新されました。 – paxdiablo

+0

こんにちは。これは非常に興味深いですが、私が行ったことは基本的なカウントセマフォーの実装だと思いますよね?私はTOMAINとTOWORKERの使用が好きです。主人は、労働者の1人がfreethreadsが増分され、複数の労働者がcond-waitで眠ることを示すメッセージを送信するまでスリープします。これはまた、キューがあることを前提としていますか?私の質問---実際にこれを試しましたか?複数の労働者が待っているとどうなりますか?私はコンドル信号が、彼らのうちの1人だけが目を覚ますことを保証すると思いますか? – vy32

1

カウントセマフォの使用について考えましたか?

+0

セマフォは、このタイプのものの標準的な解決策です。 –

+0

標準の1990年代のソリューション。 ;-) –

1

アーキテクチャの観点からは、スレッドプールの責任があります。作業者とプールの同期が存在する必要があります。

pthread_mutex_lock()またはカウント用セマフォ(sem_wait()およびsem_post())は、このような同期に適しています。

  1. initが呼び出すことにより、カウンティングセマフォのプール:それを行う1つの方法は、のように例示することができるsem_init(p_to_sem_t、0、int型のn);
  2. n workerはsem_wait();を呼び出してセマフォを取得します。
  3. プールは、sem_wait();を呼び出してワーカーが戻るのを待ちます。
  4. プールはセマフォカウントをチェックして、すべてのワーカーがパークしているかどうかを確認します。
  5. ワーカーは、終了時にロックを解除します。sem_post();
+0

複数のワーカーのうちの1人が再び参加するのを待つ場合は、手順4を手順から削除するべきです(SHOULD)。 –

+0

これは非常にシンプルでエレガントなようです。私は正直なところ、ファイルについて知らなかった---ちょうどを見ていた。作業者のどちらが終了したかを知る簡単な方法はありますか、それを把握している別の配列を維持する必要がありますか?第二の反射で – vy32

+0

、このアプローチの問題点は、メインスレッドは、それが仕事与えることを目が覚めた1把握する必要があるということである... – vy32

関連する問題