The following describes the Immediate Ceiling Priority Protocol (ICPP). According to Burns and Wellings [[1] (http://www.cs.york.ac.uk/rts/RTSBookThirdEdition.html)] this is called "Priority Protect Protocol" in POSIX and "Priority Ceiling Emulation" in Java. The Original Ceiling Priority Protocol (OCPP) has the same worst-case performance but is subtly different in the implementation.
In priority ceiling protocol, each resource is assigned a priority ceiling, which is a priority equal to that of the highest priority task which may lock the resource.
When a task lock the resource, its priority is temporarily raised to the priority ceiling, thus no task that may lock the resource is able to get scheduled.
this allows a low priority task to defer execution of a higher-priority task
This is true of any scheme involving locked resources
If the high priority task is left starved of the resources, it might lead to a system malfunction or the triggering of pre-defined corrective measures, such as a watch dog timer resetting the entire system.
Low priority tasks usually have a low priority because it is not important for them to finish promptly (for example, they might be a batch job or another non-interactive activity).
With priorityceilings, the shared mutex process (that runs the operating system code) has a characteristic (high) priority of its own, which is assigned to the task locking the mutex.