Does priority inheritance prevent deadlock?

No, and assuming it does is a dangerous misconception. Priority inheritance solves priority inversion: it temporarily boosts a mutex holder's priority so medium-priority tasks can't preempt it, bounding how long a high-priority task waits. But that mechanism does nothing about a circular wait. In a deadlock, two tasks each hold a lock the other needs; boosting either holder's priority doesn't help, because the holder isn't being preempted, it's itself blocked waiting for the other lock that will never be released. There's no forward progress to enable; the cycle is the problem, not CPU starvation of a holder. So a system using priority-inheriting mutexes (like FreeRTOS's) is still fully exposed to deadlock if it acquires multiple locks in inconsistent orders. The two problems are orthogonal: inheritance for inversion (a timing/bounding issue), and lock ordering / avoiding hold-and-wait for deadlock (a liveness/cycle issue). You need both disciplines, use inheriting mutexes to bound inversion and enforce lock ordering to prevent deadlock. Conflating them leads people to think "I used a proper mutex, so I'm safe," which is false for the multi-lock case.