0

pthreads を使用する C アプリケーションがあります。

2 つのスレッド (A と B など) の間でロック競合が発生し、B がロックを待機している間に A が最初にロックを取得します。A が完了してロックを解放すると、B はまだ取得せず、しばらくすると A が取得します再びロックします (A はループで取得および解放します)。
プロセスを gdb にアタッチし、スレッド A がロックを放棄した後にスレッド A を一時停止し、手動でスレッド B を続行すると、それを取得して必要な処理を実行します。

これは私にはデッドロックのようには見えません。スレッド B がロックを取得するのを妨げているのは何ですか? どんな助けでも大歓迎です。

サンプルコード:

スレッド A: 

while (true)  
{  
    lock.acquire(lock)  
    // Do stuff  
    lock.release(lock)  
    // Do more stuff  
}

スレッド B: 

lock.acquire(lock)  
// Do some stuff  
lock.release(lock)
4

2 に答える 2

3

アルゴリズムが飢餓に苦しんでいるようです。ロックへのアクセスをキューに入れる必要があります。

pthreads: 迅速な再ロックによるスレッド不足

また

公正なクリティカル セクション (Linux)

コメントへの回答として、ミューテックスとは（pthreadライブラリ）

ミューテックスは、次の 3 つのことを保証する (Pthread ライブラリからの) ロックです。

アトミシティ- ミューテックスのロックはアトミック操作です。つまり、ミューテックスをロックすると、他のスレッドがそのミューテックスを同時にロックできないことがスレッド ライブラリによって保証されます。

特異点- スレッドがミューテックスをロックできた場合、元のスレッドがロックを解放するまで、他のスレッドが同じミューテックスをロックできないことが保証されます。

非ビジー待機- スレッド A が、スレッド B によってロックされたミューテックスをロックしようとすると、スレッド B によってロックが解放されるまで、スレッド A は中断されます (CPU リソースは消費されません)。スレッド B がミューテックスのロックを解除すると、スレッド A が起動して実行を継続し、ミューテックスがロックされます。

公平性を保証するものではありません。

:に対する一種のリーダー ライター フェアネスにまだ関心がある場合は、pthread_rwlock_rdlockライターの飢餓を避けるために、リーダーよりもライターを優先することができます。

于 2013-02-06T19:19:58.607 に答える
0

もう1つの可能性は、Aスレッドでロックが以前に要求されており、ロック/解放が完全に解放されないことです（ロックカウントスレッドが高すぎるままです）。

飢餓は別の強力な可能性ですが、あなたの質問は「しばらくするとAが再びロックを取得する」と述べており、数マイクロ秒以上を示しています:)これは飢餓を防ぐはずです。

Aから戻るか、continueステートメントを使用して、ロックを維持することは可能ですか？

于 2013-02-06T20:15:12.350 に答える