PI와 priority ceiling을 함께 검토합니다. 현재 lock holder의 우선순위를 올리는 방식과 lock 접근 전에 상한을 예약하는 방식은 어떤 전제가 다른가요?

PI와 ceiling은 모두 priority 지연을 줄이지만 결정 시점과 필요한 정보가 다릅니다. PI는 실제 높은 priority waiter가 lock에서 block된 뒤 그 waiter의 priority를 현재 owner의 effective priority에 넣습니다. 반면 ceiling 계열은 자원별로 가능한 priority를 사전에 설정하고, protocol에 따라 mutex를 보유한 thread의 실행 priority를 acquisition 시 올립니다. POSIX의 PTHREAD_PRIO_PROTECT는 configured ceiling을 사용해 owner의 실행 priority를 높이는 규칙을 정의하지만, 이것을 모든 ceiling protocol의 접근 거부 규칙으로 확대해서는 안 됩니다. PCP나 SRP의 admission/blocking을 말하려면 그 정확한 표준이나 RTOS를 지정해야 합니다.

예를 들어 A ceiling이 8, B ceiling이 10이고 작업 H의 priority가 9라면, PI는 H가 실제로 A를 기다린 뒤 A owner를 9 수준으로 올립니다. PTHREAD_PRIO_PROTECT에서는 H가 waiter를 만들기 전에도 B를 보유하면 configured ceiling 10이 owner priority 계산에 관여합니다. 따라서 PI는 실제 경합과 ownership chain의 동적 bookkeeping이 핵심이고, ceiling은 자원 목록과 priority 등록의 완전성이 분석의 전제입니다. 둘 다 긴 임계 구역·외부 I/O를 없애지 않으며, Linux rt_mutex의 PI 설명이 Linux의 ceiling semantics를 의미하지도 않습니다.

따라서 질문의 “상한을 예약한다”는 표현을 protocol 이름 없이 구현 규칙으로 확정하면 안 됩니다. POSIX 보호 mutex를 선택한다면 ceiling 설정 실패, thread priority가 ceiling을 초과하는 경우, mutex 보유 중 priority가 어떻게 보이는지를 그 API의 오류와 상태로 검증합니다. PCP/SRP를 선택한다면 ceiling 계산표, 동시에 잠글 수 있는 자원 집합, admission 조건을 해당 RTOS 문서와 대조합니다. PI는 등록표가 덜 정적일 수 있지만 런타임 chain 갱신 비용을 부담합니다.