(itron-club 1662) 優先度上限プ ロトコルについて

[NAKAMURA Katsuyuki <milkyway __at__ ss.iij4u.or.jp>]

中村と申します。

「uITRON4.0標準ガイドブック」(パーソナルメディア社刊)の231ページで
優先度上限プロトコルについて説明していますが、この説明は間違いではないでしょうか。

上記ページの説明によれば、
「例えば、図2-13であらかじめミューテックスの上限優先度がタスク1の優先度と同じ
と決められていたとする。タスク3がミューテックスのロックをした場合、タスク3はタ
スク1の優先度で実行されているため、タスク1が起動されたり、タスク2が起動されて
も、待ち状態とはならず実行を続ける。」
とありますが、

1) ミューテックスの上限優先度がタスク1の優先度と同じと決められているとする。
-->> ミューテックスをロックしようとするタスクの内の優先度で最高の優先度の値では?
   
2) タスク3がミューテックスのロックをした場合、タスク3はタスク1の優先度で実行されて
　 いる
-->> タスク3の優先度がタスク1と同じ値に引き上げられる(優先度継承)のは、
        タスク1がタスク3のロックしたミューテックスをロックしようとしたときの誤りでは
        ないでしょうか?

「SYNCHRONIZATION IN REAL-TIME SYSTEMS A Priority Inheritance
Approach」 Rajkumar著のpp.26-27によれば、

Definition: The priority ceiling of a semaphore is defined as the priority of the
highest priority job that may lock this semaphore. 
中略
At time t0, J2 is initiated and begins execution.
At time t1, J2 locks semaphore S2.
At time t2, job J1 is initiated and preempts job J2.
At time t3, job J1 tries to enter its critical section by making
an indivisible system call to execute P(S1). However, the run-
time system finds that S2 is locked, and p(J1) < c(S2). Hence,
the run-time system suspends job J1 without locking S1. Job
J2 now inherits the priority of job J1 and resumes execution.

となっていますが・・・

この記述のp(J1) < c(S2)も間違っているような気がしますが・・・
p(J1) =< c(S2) ?

以上

----
中村　勝之