スレッド 1:
putQ
setFlag
スレッド 2:</p>
while (1) {
waitFlag
processQ
clearFlag
}
これはインタビューの質問です。スレッド 1 に while ループがあるかどうかはわかりません。しかし、答えは、スレッド 2 が再び while ループに入ると、2 つのスレッドがデッドロックになるようなものです。
デッドロックの条件を誰か教えてもらえますか? ありがとう。
スレッド 1:
putQ
setFlag
スレッド 2:</p>
while (1) {
waitFlag
processQ
clearFlag
}
これはインタビューの質問です。スレッド 1 に while ループがあるかどうかはわかりません。しかし、答えは、スレッド 2 が再び while ループに入ると、2 つのスレッドがデッドロックになるようなものです。
デッドロックの条件を誰か教えてもらえますか? ありがとう。
OPのコメントは正しいと思います。
@Gray:これはおそらくデッドロックではなく、競合状態です。それでも、アプリケーションはキューを処理せずにスタックしているため、ロックされています。
@Wugthread 1
:おそらく、キューに入れてフラグを更新している間は気付かない「些細なケース」thread 2
です。以下の行動方針を参照してください。
潜在的なロック状況:
ProcessQ
要素0(以前の要素の処理)PutQ
要素1SetFlag
ClearFlag
waitFlag
要素1は処理されない可能性があります。
編集:
もちろん、次の質問は次のようになります。how do you fix that?
答えは次のようになりますConditional Variable
(詳細についてはpthread_cond_init
、およびその他を参照してください)。
スレッド1:
PutQ
LockMutex
SetFlag
CondSignal
UnlockMutex
スレッド2:
while (1) {
LockMutex
while (FlagIsUnset)
CondWait
FlagUnset
UnlockMutex
ProcessQ
}
問題のあるシナリオの 1 つは、スレッド 1 ( T1
) が問題のコードを短時間に 2 回呼び出す場合です。考えられる行動方針は次のとおりです。
T2: waitFlag
T1: putQ
T1: setFlag
T2: processQ
T1: putQ
T1: setFlag
T2: clearFlag
T1
再びキューに何も入れない場合T2
、2 番目のアイテムは処理されません。しかし、それはデッドロックではありません。
最初のブロックの周りにループがあると仮定すると、例はセマフォでカウントすることの重要性に注意を喚起しようとしていると思います。例の「フラグ」はカウントされないため、最初のループを複数回通過すると複数のアイテムがキューに入れられますが、フラグは 1 回しか「設定」できないため、2 番目のループは 1 回しかトリガーできません。セマフォはV
上のループのそれぞれに対して 1 回カウントアップするため、2 番目のループは でカウントを減らしながら必要な回数だけ実行されますP
。