> Priority boost to 31 was never implemented, but boosting the owner of a mutex to the priority of
a waiter has.
Now consider what happens if mutex owner goes blocking on, say, a semaphore that is supposed to get signaled by someone who has no relation to mutex whatsoever, and who signals it in order to indicate
that a certain event has occurred (i.e. you don’t even necessarily know who it is - unlike mutexes, semaphores don’t have their owners, do they). As you can see, an attempt to implement priority inheritance protocol has no effect in this situation whatsoever - boosting owner’s priority does not offer any solution in this situation…
In KM, raising to dispatch (ie acquiring a spin lock) is effectively like raising to 31 because the code
becomes un-promptable (except for interrupts).
Yes, and, at this point, spinlock owner is already unable to go blocking - at this point you, indeed, get the true semantics of priority ceiling protocol, because spinlock owner is unable to enter the unbounded wait. However, you get it at the cost of disabling a dispatcher…
Anton Bassov