2013-01-09 8 views
6

は、次のような状況を考えてみましょう。待ち(POSIXスレッド、C++)

bar()がfooの状態を決して変更しないので、bar()が複数回並行して実行されることは完全に良い(そして望ましい)。

外部から(別のスレッドからではなく、「ワーカー」スレッドから)fooの状態を変更する必要があるときに問題が発生します。fooをロックして呼び出しスレッドをブロックする方法最後のワーカースレッドはbar()で終了し、fooを再び解放するまで、すべてのワーカースレッドはbar()でブロックされますか?

もちろん、bar()の実行中にロックされたままのミューテックスを使用することはできません。なぜなら、そこには並行性がないからです。

アイデア?あるいは、これらのタイプの問題のためのより良い設計がありますか?

+3

[Readers-writer lock](http://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock) – hmjd

+0

を参照してください。なぜbar関数の呼び出しの前後でワーカースレッドにミューテックスを導入していないのですか?また、foos状態を変更したい呼び出し側のスレッドにも適用されます。呼び出し側のスレッドはmutexをロックし、安全にfooの状態を変更することができません。 – mgr

+2

'pthread_rwlock_t'があなたにとって興味深いかもしれません。 – WhozCraig

答えて

4

私は労働者のどれもがライターがそれを更新できるようにFOOを使用していないことを、あなたが達成しようとしているかわからないが、それが問題でない場合、その後だけにread/write mutexの労働者を使用します読み取りロックを取得するために、ライターを取得します)。

foo Copy-on-Writeの作成を検討することをお勧めします。これにより、同期オーバーヘッドをゼロに近づけることができます。あなたはそれを達成するためにshared_ptr atomicallyを使用することができます。

+0

pthread_rwlock_tへのすべてのポインタのおかげで! – Pontomedon