質問とコードを読んで、私も言います(A)。タスクを完了する前にプロセスをプリエンプトすることはできないと想定しています。
初期状態はS0=1
S1=0
S2=0
であり、私たちが知っていることから、P1
正確P2
に 1 回実行されます。
並行プロセスは複雑になる可能性がありますが、私が考える方法で人々が欠点を見つける流れを説明しようとしています。それは問題ありません。私も学ぶためにここにいます。
ここで、プロセスの順序に応じて異なる結果が得られる状況がいくつかあります。
P0 -> P1 -> P0 -> P2 -> P0 = Three times
P0 -> P1 -> P2 -> P0 = Twice
P0 -> P2 -> P1 -> P0 = Twice
これにより、少なくとも 2 倍の答えが得られます。
編集:
これはすべて、semaphore == 0 のときに wait() がブロックされ、release() が semaphore = 1 を設定するという仮定の下で行われます。
プロセスがいつでも中断できる場合、物事は興味深いものになります。
P0 starts out running because S0=1 at start
P0 print '0';
P0 release(S1);
-- here S1 may take over or not --
P0 release(S2);
-- here S2 may take over or not --
P0 goes back to wait(S0)
-- here P0 continues or if S1 *and* S2 have not run blocks --
-- it may also be that only S1 or S2 ran and now the other will run --
今、私は物事がどのようにうまくいくかを視覚化する方法を見つけようとしましたが、それをコードブロックに入れる良い方法を見つけることができませんでした.
S1 と S2 の両方ができるだけ早く実行された場合、セマフォはバイナリであり、2 つの状態のうちの 1 つしか存在できないため、P0 は 2 回しか実行されませんが、P0 が通過するまで S1 または S2 のいずれかを遅らせるほどスケジューリングがひねくれている場合P0 が 3 回実行されます。
しかし、この質問は中断可能なプロセスを意図したものではなかったと思います。